query string、格式化、深拷贝、请求取消这些场景，很多时候不需要额外装库——JavaScript 原生 API 已经能表达清楚，前提是先看兼容性和团队成本。

Context 混放状态会让一次输入拖着半个页面重渲染——问题不在 Context 本身，而在状态该放在哪一层、归谁管，拆分职责、区分 state 和 actions 才是根本解法。

Bun 的速度收益到底落在哪一段反馈链路，兼容性能扛到什么程度，成熟前端项目又为什么不该一口气全量迁移，从低风险脚本切入才是稳妥的验证方式。

调通工具只是开了个头，参数错了、接口超时、结果不完整，这些失败路径没处理好，Agent 很快会变得不可靠；这篇讲清楚怎么统一处理工具错误、参数校验和调用日志。

表单值、字段状态、错误状态、流程状态混在一个对象里迟早会失控——拆开这四类状态，异步校验的竞态和多阶段提交才有地方安放。

结合几次业务里踩过的坑，聊聊 Prompt 工程在真实系统里到底该管什么：输入结构、输出约束，以及哪些判断不该交给模型自由发挥。

结合几次 AI 应用迭代经历，聊聊为什么系统输出不稳时，很多问题其实不在模型，而在上下文怎么组织。

首屏指标再好看，用户点一下筛选还是能卡半拍——INP、长任务拆分、React 重渲染边界，才是交互性能真正要盯的地方。

同一个错误码在不同页面提示不一致、表单字段错误只会弹 toast，这篇讲清楚怎么把网络错误、业务错误、表单错误和页面反馈重新分层。

记录和 AI 编程助手协作时更稳定的工作方式：先读代码、拆任务、说明改动，再执行和验证。

手写 scroll 监听算进度容易卡顿，也难维护；CSS view() 能把这类动画交还给浏览器，但兼容降级和动效克制要做到位。

Shadow DOM 里重复插入 style 的维护成本有多高，Constructable Stylesheets 适合什么场景，它和普通 CSS 该怎么分工，这篇讲清楚。

Tooltip、Dropdown、Popover 的定位维护成本一直很高，这篇讲清楚 CSS Anchor Positioning 能省掉哪部分测量代码，以及真实项目里为什么不会立刻全量替换。

AI 对话的逐字输出不是前端定时器假装出来的；SSE 和 fetch 流式读取各有适用场景和失败处理。

批量请求不能只写一个 Promise.all；我更关心同时执行数量、失败重试、取消和用户等待时间怎么平衡。

把主题、语言这类值塞进依赖数组，会让连接跟着无关状态反复重建；useEffectEvent 把“同步条件”和“事件里读最新值”这两层拆开，比 useRef 的写法更直接。

评论接口耗时不稳定，手搓临时评论、失败回滚这些边角逻辑很快就绕不清楚——useOptimistic 把“用户看到的状态”和“服务端确认的状态”彻底拆开了。

什么时候该让模型自己规划，什么时候必须把流程写死，这篇结合两次自动化项目的实际取舍聊聊怎么判断。

从业务落地角度讨论 AI 应用评估该看什么，为什么只看 Demo 很容易高估系统能力。

React Server Components 语法不难，难在判断哪些组件该留在服务端、哪些交互必须下放到客户端，数据获取、缓存和错误处理都要跟着这条线重新划分。

页面慢不一定该上 Edge——渲染位置离用户近了，数据如果还在中心区域，那一跳只是换了个地方出现，缓存策略和运行时限制才是真正要先算清的账。