陌上寒

数据可以在「服务端（渲染前）」「客户端（交互后）」「构建时（静态）」三个位置获取——首选服务端（更快、更安全、利于 SEO、包更小），客户端只用于「必须交互后才发」或「频繁变化」的数据。

赞(0)陌上寒2026-10-1609-服务端渲染与框架 阅读()去评论

水合（Hydration） 是「客户端复用服务端生成的 HTML、绑定事件、变成可交互」的过程；水合不匹配（hydration mismatch） 发生在「客户端首次渲染的结果与服务端 HTML 不一致」时——常见原因是用了随机值/当前时间、依赖了浏览器信息、渲染了非法 HTML 结构。

赞(0)陌上寒2026-10-1609-服务端渲染与框架 阅读()去评论

Server Component 在服务端执行（可直接查数据库、代码不进客户端包，但不能有状态/事件/浏览器 API）；Client Component 用 "use client" 标记（可交互、有状态）；"use client" 是一条边界——它导入的所有模块都会变成客户端代码。

赞(0)陌上寒2026-10-1609-服务端渲染与框架 阅读()去评论

读完《饥饿的盛世》，我最强烈的感受不是愤怒，而是一种缓慢渗入骨髓的寒意。张宏杰写的是乾隆时代，却让我不断想到一个更普遍的问题：当我们说一个时代“伟大”时，究竟是在说谁的伟大？这本书没有停留在对康乾盛世的简单翻案上，而是把那个被反复歌颂的盛世...

赞(0)陌上寒2026-10-16阅读 阅读()去评论

App Router 用「目录结构即路由」——app/ 下的目录是路由段，page.tsx 是页面，layout.tsx 是共享布局，loading.tsx/error.tsx 提供边界；组件默认是 Server Component，要交互才加 "use client"。

赞(0)陌上寒2026-10-1609-服务端渲染与框架 阅读()去评论

四种渲染方式的本质区别是「HTML 在哪里、什么时候生成」——CSR 在浏览器（首屏慢、SEO 差），SSR 每次请求在服务端，SSG 构建时生成（最快），ISR 静态生成 + 后台增量再生。

赞(0)陌上寒2026-10-1609-服务端渲染与框架 阅读()去评论

Worker 的价值是「把 CPU 密集的工作从主线程搬走」——它直接改善 INP（交互延迟） 与「动画流畅度」；真正的工程难点是「通信成本（结构化克隆）、生命周期（池化复用）、以及构建打包」这三件事。

赞(0)陌上寒2026-10-1608-副作用与错误处理 阅读()去评论

Feature Flag 的价值是「把『发布代码』与『放出功能』解耦」——所以它的核心不是「一个开关」，而是「一致的灰度分桶（同一用户稳定在同组）+ 本地快速求值 + 拉取失败时的兜底 + A/B 的曝光记录」，而最大的风险是「开关变技术债」。

赞(0)陌上寒2026-10-1608-副作用与错误处理 阅读()去评论

埋点最难的不是「怎么发一条数据」，而是「发得对（事件与属性有规范）、发得准（曝光判定与去重）、发得全（不漏）、发得不重（不重复）、丢得起（上报失败可重试）、合规（不采集隐私）」——所以埋点是一个「数据采集系统」，而不是「一个 track 函数」。

赞(0)陌上寒2026-10-1608-副作用与错误处理 阅读()去评论

前端错误监控的核心是「把『压缩后的一行报错』还原成『能定位到源码的行为链路』」——所以四件事缺一不可：全局捕获（含跨域脚本）→ Sourcemap 还原 → 指纹分组去重 → 面包屑/上下文（用户当时在干什么）。

赞(0)陌上寒2026-10-1608-副作用与错误处理 阅读()去评论