团队要做一个多人协同编辑的功能，传统的后端合并冲突加乐观锁在多人同时改同一段内容时很难写干净；记录一下改用 CRDT、用 Yjs 落地协同文档的过程，以及这套方案要付出的代价。

Svelte 4 的响应式声明依赖编译期静态分析，没法在组件外的普通模块里复用；Runes 用 `$state`、`$derived`、`$effect`、`$props` 这套显式 API 解决了这个问题，这篇记录我们把内部发布看板一部分模块迁移到 Runes 后的具体判断。

几十万个点位的散点图在 Canvas 2D 下卡到没法交互，换 WebGL 也只是把卡顿从主线程挪到了每帧几千次 draw call 上——记录我排查这个瓶颈、最终用 WebGPU 的 Compute Shader 重写数据聚合逻辑的过程。

评估一个离线优先的文档编辑器要不要把数据存进浏览器时，IndexedDB 的异步 API 在高频写入场景下写起来啰嗦、性能也一般，OPFS 提供的同步访问句柄和更接近真实文件的操作方式是另一条路，这篇讲清楚它的存储模型、权限模型、和 IndexedDB/Cache Storage 的分工，以及配额和数据清除时该怎么应对。

shadcn/ui 不发 npm 包、直接把组件源码装进你的仓库。聊聊这种 copy-in 模式的好处、维护成本、和传统组件库（Antd/MUI）的取舍。

qiankun 的 JS 沙箱怎么隔离子应用的全局变量污染：拆解 ProxySandbox 和 LegacySandbox 为什么要设计 fakeWindow、with、函数绑定和生命周期补丁。

从 Vue ref、Solid signal 到 TC39 的 Signals 提案，聊聊信号这套响应式模型解决了什么、polyfill 怎么用、以及它和现有框架的关系。

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

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

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

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

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

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

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

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

Next.js 到底该在什么项目上用：纯中后台为什么大概率不划算、`'use client'` 边界怎么画、App Router 缓存分几层、以及静态生成和流式渲染在内容型站点里的实际取舍。

桌面端选型不该从'哪个更新潮'开始，该从三个问题开始：目标机器是什么环境、包体和内存有多敏感、团队有没有人能写 Rust。拿一个内部工具在 Tauri 1.5 和 Electron 28 上各跑了一遍，体积、内存、WebView 兼容性、Rust 侧 invoke、生态成熟度的实测差异都在这里。

组件从能复用到真好用，差的是抽象边界、受控状态和组合 API 的取舍。什么时候该抽、什么时候该忍住重复，业务表格越抽越大是最直接的反例。

Web Components 值不值得用，判断标准是组件要不要跨框架、跨页面分发。这篇讲清它适合用在什么场景，以及表单集成、样式互不干扰、事件通信这几处必须提前踩过的成本。

组件的可复用性不等于可配置项越多越好，边界该划在哪：基础组件收着做、业务组件贴场景做，props 表达语义而非样式细节，扩展口只当逃生通道。这篇把这几条判断标准讲清楚。

同一份状态该进 store、进 URL 还是交给 React Query，判断依据是它的生命周期和归属，而不是写起来方不方便；这篇把 Zustand 的拆分、选择器、派生和持久化这几个取舍讲清楚。

从 Vuex 迁移到 Pinia，state/getters/actions 这几个 API 名字换起来最快，哪些状态值得全局化、模块该怎么拆、持久化和 SSR 水合的坑怎么避开，才是真正花时间的地方。

组件 API 一旦被多个页面引用就很难改。这篇整理 props 粒度、事件命名、v-model 边界和插槽尺度的判断标准，附带一个从 Vuex 挪到 Pinia 时暴露出来的耦合案例。

Composition API 好不好用，关键不在 API 本身，而在按什么维度拆代码——`setup` 里没有强制分区，状态、请求、事件、表单全塞进一个函数体也能跑，但两个月后改起来会很难受。

Composition API 不是给所有组件用的新写法，它解决的是逻辑跨选项分散的组织问题。这篇整理我们判断“要不要重写”的标准，以及一个真实组件的重写过程。

重置按钮点下去只有一半字段回到了初始值——顺着这个现象拆开看，是 Vue 2 Mixins 的选项合并策略在两个同名方法之间做了取舍。梳理合并规则、命名冲突的隐蔽性，以及普通函数、组件组合、Composition API 三种替代方案各自的适用边界。

Vue 2 用 Object.defineProperty 逐个劫持属性，新增字段视图不更新，得靠 $set；Vue 3 换成 Proxy 整体拦截，这个动作差异背后是响应式机制的重写。这篇顺着这个差异往下拆，从 get/set 拦截讲到 ref/reactive 怎么选、解构为什么会断连接。

单文件组件写起来舒服，但没有天然的分寸感——请求、状态、模板、样式全放一个 .vue 文件里也能跑。这篇讲清楚组件该按什么标准拆、请求逻辑该不该下沉到服务层、样式该归到哪一层，用一个从几十行长到七百多行的用户资料页组件贯穿说明。

图表只画一半、容器宽度偶发性拿到 0，问题通常不在图表库，而在初始化时机。这里把 `created`、`mounted`、`activated` 和父子组件执行顺序放回同一个现场里理顺。

列表顺序变了、数据状态也对，页面上的复选框却勾到了别人身上——这类渲染错位的根子在节点复用策略。这里把 VNode、diff、`key` 和节点复用的边界重新讲清。

权限改造看起来像“把菜单过滤一下”，真正要动的却是整套路由守卫、动态路由注入、刷新恢复和退出清理。这里把这些环节按项目改造顺序串起来。

一个近百字段、联动复杂的商品表单，最先暴露的问题往往不是字段多，而是“万能输入框”已经失控。这里从 800 行 `AppInput` 出发，把表单组件该怎么拆重新讲清。