Yukiの小窝

第 5 期：工作三个月，离职休息与秋招准备

Sun, 07 Jun 2026 04:00:00 GMT

情绪与状态：疲惫与决定

这周开始感觉就没有什么精神，什么也不想做，感觉是累到了，而且北京不知道为什么天气好干。

下定决心离职好好休息了。不知不觉也已经实习三个月了，这段时间主要都在做业务方面的需求，感觉也好无聊，学习不到新的东西。而且刚入职第一个月就把我调整到这个组，做的还是之前组的内容，好边缘，感觉迟早要完。之前部门一下从 8 个人裁掉 3 个，太恐怖了。

不过自我感知，真不知道什么用户在 ks 买东西…可能层级不一样吧。很难想象。

接下来的计划：休息、旅游与秋招

下周离职回去好好休息，然后准备秋招 + 出去旅游玩 w。打工赚的钱终于可以让自己好好放松了。

接下来的重点：

旅游放松：用自己赚的钱好好放松一下。
完善项目：回去完善自己的新项目。
更新旧项目：update 自己的老项目。

面试与八股复习

本周还面试了两场，自己八股都快忘完了。不过面试官都问八股，感觉这个组也不怎么样。看着别人都是全程问 AI 之类的，怎么到我这里就全是八股轰炸。

不过自己算法能力还是不太行，还是需要加强。其他的计划就是再复习一下八股。

离职跑路 w

携程集团面经

Thu, 04 Jun 2026 06:00:00 GMT

携程集团

面试时间

2026_0604-14:00

面试内容

介绍你的项目，包括使用方和使用场景是什么？
是否仍在快手实习？
询问跨域 iframe 实时预览功能。
解释一下 React Hooks
是否了解 React 的 forwardRef？
事件循环
事件循环输出题
解释 HTTP 缓存机制
协商缓存 ETag 和 Last-Modified 的区别。
请说明 CommonJS 和 ES6 Module 在变量作用域上的主要区别。
请解释 Flex 布局的基本概念
说明 flex: 1 是哪些属性的简写？
flex: auto 是哪些属性的简写？
是否了解 openSpec
页面性能优化
怎么实现图片懒加载
css 动画
animation 的具体使用
手撕：leetcode 128. 最长连续序列
AI 相关内容的讨论
业务方面（旅游门票）

面试复盘总结（核心问题精讲）

1) React Hooks 与 `forwardRef`（Q4, Q5）

解释 React Hooks

Hooks 出现的核心目的是解决函数组件没有状态（State）和生命周期的问题。它让函数组件能够“钩入” React 的状态管理和副作用处理机制（如 useState、useEffect），同时解决了类组件（Class Component）中 this 指向混乱、生命周期逻辑割裂（同一个业务逻辑被拆分到 DidMount 和 DidUpdate 中）以及逻辑复用困难（只能靠高阶组件 HOC 或 Render Props 导致嵌套地狱）的问题。

为什么需要 `forwardRef`？

痛点：在 React 中，ref 不能作为普通的 props 往下传。如果你给一个自定义函数组件传 ref，React 会直接报错，因为函数组件没有实例。
作用与代码演示：forwardRef 用来包裹函数组件，把父组件传进来的 ref 拦截下来，传给内部节点。最佳实践是配合 useImperativeHandle，只暴露特定方法给父组件，而不是暴露整个 DOM（避免破坏封装）。

import { forwardRef, useImperativeHandle, useRef } from "react";

// 子组件：被 forwardRef 包裹，拦截 ref 并自定义暴露的方法
const MyInput = forwardRef((props, ref) => {
  const inputRef = useRef(null);

  // 只暴露 focus 和 clear 方法给父组件
  useImperativeHandle(ref, () => ({
    focus: () => {
      inputRef.current.focus();
    },
    clear: () => {
      inputRef.current.value = "";
    },
  }));

  return <input ref={inputRef} placeholder="请输入..." />;
});

// 父组件：可以直接调用子组件暴露的方法
function Parent() {
  const myRef = useRef(null);

  return (
    <div>
      <MyInput ref={myRef} />
      <button onClick={() => myRef.current.focus()}>聚焦</button>
      <button onClick={() => myRef.current.clear()}>清空</button>
    </div>
  );
}

2) CommonJS 与 ES6 Module 的变量导出差异（Q10）

这是一道极为经典的模块化底层题：“假如模块里导出了一个数字 5，过一会儿模块内改成了 6，外部拿到的分别是多少？”

CommonJS (CJS) —— 值的浅拷贝

module.exports 导出的是一个对象的浅拷贝（类似按值传递）。

// a.js (CommonJS)
let num = 5;
setTimeout(() => {
  num = 6;
}, 1000); // 1秒后内部改为 6
module.exports = { num };

// b.js
const a = require("./a.js");
console.log(a.num); // 输出 5

setTimeout(() => {
  console.log(a.num); // 2秒后再打印，依然是 5。因为 require 时复制了那一瞬间的值
}, 2000);

ES6 Module (ESM) —— 动态只读引用（Live Bindings）

export 导出的是一个动态映射的内存地址引用。外部拿到的值会随内部变化而动态变化，且该引用在外部是只读的。

// a.mjs (ES6 Module)
export let num = 5;
setTimeout(() => {
  num = 6;
}, 1000); // 1秒后内部改为 6

// b.mjs
import { num } from "./a.mjs";
console.log(num); // 输出 5

setTimeout(() => {
  console.log(num); // 2秒后再打印，输出 6！动态绑定了 a.mjs 内存

  // num = 7; // 如果强行在外部修改，会抛错 TypeError: Assignment to constant variable
}, 2000);

3) Flex 布局：`flex: 1` vs `flex: auto`（Q11, Q12, Q13）

Flex 基本概念

Flexbox（弹性盒子）是一维布局模型，专门用于处理空间分布和对齐。它由**主轴（Main Axis）和交叉轴（Cross Axis）**构成，能自适应父容器的尺寸变化，解决传统浮动（float）布局中垂直居中困难、等高列难实现等问题。

`flex` 简写属性的秘密

flex 其实是三个属性的简写组合：

flex-grow: 放大比例（默认 0，不放大）。
flex-shrink: 缩小比例（默认 1，空间不足时会缩小）。
flex-basis: 分配多余空间之前，元素的基础大小（默认 auto，依据内容大小）。

拆解代码演示：`flex: 1` vs `flex: auto`

假设我们有两个容器，分别放了不同长度的内容：

<div class="parent">
  <div class="box a">短</div>
  <div class="box b">我是一段非常非常长的文本内容</div>
</div>

<style>
  .parent {
    display: flex;
    width: 600px;
    border: 1px solid #ccc;
  }
  .box {
    border: 1px solid red;
  }

  /* 场景1：绝对平分（无视内容） */
  .a,
  .b {
    flex: 1;
  }
  /* 结果：A 和 B 各占 300px，一模一样宽。
   原理：等同于 flex-basis: 0%，大家起点都是 0，直接把 600px 一分为二。*/

  /* 场景2：相对平分（尊重内容大小） */
  .a,
  .b {
    flex: auto;
  }
  /* 结果：B 会比 A 宽得多。
   原理：等同于 flex-basis: auto。系统先算出 A 和 B 文本原本的宽度，
   然后从 600px 中减去这两个原始宽度，剩下的空白区域再平分给 A 和 B。*/
</style>

4) CSS 动画与 `animation` 属性详解（Q17, Q18）

在 CSS 中实现动画通常分两步：定义关键帧 和 调用动画属性。

第一步：定义 `@keyframes`

指定动画在不同百分比时间节点（0% 到 100%，或 from 到 to）的 CSS 状态。

第二步：使用 `animation` 简写属性

animation 也是一个超级简写属性，面试时能把下面 8 个子属性说清楚，绝对加分：

/* 顺序通常为：name | duration | timing-function | delay | iteration-count | direction | fill-mode | play-state */
animation: slideIn 2s ease-in-out 0.5s infinite alternate forwards running;

拆解详解：

animation-name：绑定的关键帧名称（如 slideIn）。
animation-duration：持续时间（如 2s）。
animation-timing-function：缓动曲线，决定速度节奏。常用 linear (匀速), ease-in (渐显加速), cubic-bezier (自定义贝塞尔曲线)。
animation-delay：动画延迟多久开始（如 0.5s）。
animation-iteration-count：播放次数，常用 infinite（无限循环）或具体数字。
animation-direction：播放方向。
- normal（正向）
- reverse（反向播放）
- alternate（交替播放，比如去程正放，回程倒放，常用于呼吸灯/摇摆效果）。
animation-fill-mode（非常重要，面试常考）：动画结束（或等待期）的状态。
- forwards：动画结束后，元素停留在最后一帧的状态。
- backwards：动画延迟等待时，元素提前应用第一帧的状态。
- both：同时应用上述两者。
animation-play-state：动画的运行状态。可以通过 JS 控制它为 paused 或 running 来实现悬停暂停动画的效果。

知乎一面面经

Wed, 03 Jun 2026 09:00:00 GMT

知乎一面

面试时间

2026_0603-17:00

面试题目

为什么打算离开快手？
能实习多久？
你在项目中主要负责什么？
SSR 与 CSR 的区别及应用场景
SSE 流式返回机制
图表生成失败怎么考虑？
低代码动态表单怎么联动？
怎么做的提前加载内容？
弱网情况下用户快速滑动图片列表怎么能够好的让用户访问？
MCP Server 怎么理解？
解释事件循环
事件循环输出题
var/let/const 区别
箭头函数特性（this 指向、不能作为构造函数，没有 prototype）
H5 页面顶部固定搜索框 + 下方自适应列表的布局方案
虚拟 DOM 作用及 key 的作用（为什么不能用 index）
全局状态管理使用场景
跨域问题
前端安全问题（恶意脚本注入、转译库）
React 原生支持转义吗？
AI 上下文治理（污染、回退、Sub Agent 隔离、压缩、skill）
反问
对我的建议
是否转正及工作内容范围（C 端/M 端、全栈）

面试复盘（核心问题精讲）

1) 低代码动态表单怎么联动？（Q7）

低代码表单的核心是 “数据驱动视图”，联动的本质是 依赖收集与副作用（Side Effects）派发。

比如：选择了“省份 A”，需要发请求拉取并回填“城市列表 B”。

完整解法（分层架构设计）：

第一层：联动规则的 Schema 定义

配置表单时，我们不能直接写 watch 或 useEffect，只能在 JSON Schema 中通过特定的关键字（如 dependencies / x-reactions）来描述“谁依赖了谁”、“满足条件后干什么”。

场景：选择“部门(dept)”后，自动拉取该部门的“员工列表(users)”并回填下拉框。

{
  "dept": { "type": "string", "title": "部门" },
  "users": {
    "type": "string",
    "title": "员工",
    "x-reactions": {
      "dependencies": ["dept"],
      // fulfill 定义条件满足后执行的动作
      "fulfill": {
        // 1. 同步联动：改变自身 UI 状态（比如显示出来）
        "state": { "visible": "{{ !!$deps[0] }}" },
        // 2. 异步联动：触发一个预定义的请求动作，并把数据回填到 dataSource
        "run": "fetchUsersByDept($deps[0])"
      }
    }
  }
}

第二层：状态管理树（Form Store）

低代码引擎在运行时，必须有一个统一的 Store（通常基于 Proxy、MobX 等响应式库）。这个 Store 里不仅存用户填的 values，还要存每个组件内部的元数据：

Values:
Field State: visible, disabled, loading（组件自带状态）
Component Props: dataSource（下拉框的备选项数据）

第三层：副作用派发与异步回填执行流（核心）

当用户在界面上切换了“部门”时，整个执行流如下：

值变化拦截：用户切到“前端组”，触发 Store.setValues('dept', '前端组')。
触发依赖链：引擎内部的依赖收集器（Dependency Graph）发现 users 字段订阅了 dept，于是拿到 users 对应的 x-reactions 规则。
沙箱求值：取出 "{{ !!$deps[0] }}"，在安全的 new Function 沙箱中执行，得到 visible: true。同时发现有 run: "fetchUsersByDept" 这个异步动作。
异步请求与回填：
- 引擎立刻把 users 字段的状态设为 loading: true（此时界面上下拉框会转圈）。
- 引擎调用注册在全局的 fetchUsersByDept('前端组') 接口拉数据。
- 接口返回 [{ label: '张三', value: '1' }]。
- 引擎派发更新：Store.setFieldState('users', { loading: false, dataSource: 拿到数据 })。
视图更新：底层组件（如下拉框）因为绑定了 Store 的 dataSource，自动重新渲染，数据回填完成。

第四层：防死循环（DAG 拓扑排序）

如果业务配置非常复杂：A 变化 -> 拉取 B -> B 回填后触发 C -> C 又修改了 A。这会导致死循环和不断发请求。

防御机制： 引擎在解析 JSON 初始化表单时，会先构建一张有向无环图（DAG）。如果发现依赖成环（A->B->C->A），初始化阶段直接抛错，拒绝渲染，从而从根源切断死循环问题。

2) 提前加载内容与 Intersection Observer 的 margin（Q8）

【纠点预警】：面试中如果提到“设置成负的来提前加载”，这里其实是个常见误区！ 提前加载需要把 rootMargin 设置为“正值”（Positive）。

原理解析： Intersection Observer 默认在元素的边界刚好碰到视口（Viewport）时触发。

正值（如 rootMargin: "0px 0px 500px 0px"）：相当于把视口的判定范围向下扩大了 500px。元素还在屏幕下方 500px 时，观察器就认为它“进入”了，从而触发回调。这才是做“提前加载”（预加载）的正确姿势。
负值（如 rootMargin: "-50px 0px"）：相当于把视口向内收缩了 50px。元素必须完全进入屏幕并且再往上走 50px 才算“可见”。这通常用于**“精准曝光埋点”**（防止用户飞速滑过也算曝光）。

补充：其他提前加载手段

<link rel="prefetch"> / <link rel="preload">：在浏览器空闲时提前下载下一页资源。
Hover 预加载：当用户鼠标悬停在链接上时（大约有 200-300ms 的犹豫时间），提前发请求拉取数据。

3) 弱网 + 快速滑动长列表的图片优化（Q9）

弱网加极速滑动，最大的问题是：滑过的废弃图片塞满了浏览器的并发请求队列（Chrome 默认最多 6 个并发），导致当前停下来真正该看的图片一直处于 Pending 状态。

完整的解决方案（可层层递进向面试官展示）：

取消废弃请求（最核心）：配合 Intersection Observer，如果元素很快滑出可视区（或扩大后的可视区），立即在 unobserve 的同时中断请求。如果用 fetch，可以用 AbortController；如果是 img 标签，可以将 src 置空（img.src = ''）。
防抖/延迟加载判断：不要一进入可视区就立马加载。定一个 100ms 的延迟，如果 100ms 内元素又滑出去了，就不发请求。（过滤掉飞速滑动途经的图片）。
渐进式占位（骨架/低清）：请求真正大图前，先显示极小体积的缩略图（LQIP）、或者用 Blurhash（用一串几十字节的字符串渲染出色彩模糊的占位），给用户心理预期。
图片格式降级：通过 CDN 参数，弱网下自动请求压缩率更高的 WebP/AVIF 格式，或者降低 quality 参数。

4) 箭头函数特性底层剖析（Q14）

回答箭头函数不要只背诵，要告诉面试官“为什么”。

没有自身的 this（词法作用域绑定）：普通函数的 this 是在调用时决定的（谁调用就指向谁）。而箭头函数的 this 是在定义时根据外层上下文（Lexical Context）决定的。因为它自身压根没有 this，所以你用 .bind()、.call()、.apply() 强行改也没用。
不能作为构造函数（不能 new）：因为 JS 规范里，箭头函数并没有内部方法 [[Construct]]。当你对它使用 new 关键字时，JS 引擎去寻找 [[Construct]] 找不到，直接抛出 TypeError。
没有 prototype 属性：既然不能被 new 实例化，那它就不需要原型链去给实例继承属性，所以引擎在创建箭头函数时直接省去了 prototype 属性（节约内存）。
没有 arguments 对象：不能用 arguments 获取参数，现代 JS 推荐统一使用 ...args（剩余参数）来替代。

5) 前端安全与 React 转义机制（Q19 & Q20）

React 原生支持转义吗？（Q20） 答案是：原生支持，且非常安全。

机制：在 React 中，当你写 <div>{userInput}</div> 时，React 的渲染引擎底层调用的是 textContent 而不是 innerHTML。所有传入的大括号 {} 变量，在渲染到 DOM 之前都会被强制转换为字符串。哪怕你传入的是 <script>alert(1)</script>，页面上也只会原样显示这串字符，而不会去执行它。
特例：React 唯一的后门是 dangerouslySetInnerHTML={{ __html: userInput }}。这个属性名字故意取得这么长、这么吓人，就是为了提醒开发者“这很危险”。

前端安全问题（恶意脚本注入、转译库）（Q19） 这就是经典的 XSS（跨站脚本攻击）。如果在 React 里非要渲染富文本（比如从后端拿到了 Markdown 转换后的 HTML，必须用 dangerouslySetInnerHTML），就必须经过转译（Sanitize）。

防范手段：

转译库（Sanitizer）：千万不要自己写正则替换，非常容易被绕过。业界标准是使用 DOMPurify。把脏字符串扔进去 DOMPurify.sanitize(dirtyHtml)，它会基于一个严苛的白名单，把里面夹带的 <script> 标签、javascript:void(0) 链接、onerror 属性全部剔除，返回干净的 HTML。
CSP（内容安全策略）：在 HTTP 响应头加上 Content-Security-Policy: default-src 'self'，从源头告诉浏览器：只能执行自己域名下的脚本，就算是漏网之鱼被注入了第三方脚本也执行不了。
Cookie 安全：把鉴权 Token 存到 Cookie 时，必须加上 HttpOnly 属性。这样就算 XSS 攻击成功，黑客的 JS 代码也读不到你的 Cookie（无法发回给黑客服务器）。

劳作与远行交叠，夜修与心愿同起

Sun, 31 May 2026 13:30:00 GMT

上周忘记写了，这次把 5.18 ~ 5.31 合在一起记一下。

这两周整体节奏很像“混研 + 低代码 + 旧项目”三件套：白天写业务，晚上提测修 bug，偶尔被线上问题捅一刀 (T_T)。

工作：混研 + 低代码的日常磨耗

1) 你根本不知道页面是源码还是低代码

同一套页面，有的在源码里，有的在 schema 里。想改一个小问题，先得用 search 找关键词——在 schema 里的就是低代码，不在的就是源码。

低代码改起来比源码更麻烦：字段多、联动杂、发布链路还不透明。改完才发现“发布的不是我这套”，一度迷路。最后还是问 onCall + mentor 才把链条梳清楚，准备写成文档给后人 (´-ω-`)。

混研这块更痛苦：你根本不知道页面是源码还是低代码，只能靠 search 关键词，看落在 schema 里的就是低代码，其余才是源码。对外是同一页面，对内是两套世界，改起来像在拆盲盒。

维护这个 M 端一度像坐牢，但这两周慢慢摸清了发布链路和字段套路，现在算是“能游刃有余地坐牢”了（至少不会每天都懵）。

2) 老项目线上问题 + 三平台兼容

这周还出了两个线上问题，全是五年前的项目。产品文档写的是“只改一个平台”，结果上线后发现要兼容三个平台……

更难受的是逻辑还要求“新逻辑不兼容老逻辑”，结果一上线就报错，只能临时补兼容。到最后我都开始害怕上线了。

3) 业务逻辑循环：提测 → 修 bug → 再提测

前人离职的代码问题真的多：需求里没有的按钮还被加上了、低代码页面结构像谜题。周一晚上提测，周二修 bug，周三再提测……循环跑了好几次。

不过好消息是：这周上线终于平稳了，线上 bug 也修干净，稍微松了一口气。

周四周五留出了一点时间，可以慢慢补学习和复盘，不再是“上班打仗、下班救火”的节奏。

求职：投递不顺 & 一点点希望

投了一周几乎没怎么约到面试，太难了 (´•̥̥̥ω•̥̥̥`)。两周只约到一个携程的面试，希望能过 (ง •_•)ง。

还以为会被百度面试官捞，结果感觉像“大家都说你优秀，横向没问题”，然后就没有然后了（养蛊感拉满，欺骗感情呜呜）。

更扎心的是：暑期 3 月就投了，连笔试都没发。秋招到底会怎样，还挺迷茫的。现在这边一直做业务迭代，学不到更多系统性的东西，很想遇到一个能带我走更远的 mentor。

但也舍不得工资（现实就是这样），所以只能继续努力投 + 继续做任务两头跑。希望能遇到一个靠谱 mentor，哪怕不教我，至少给我指个路。

学习：设计模式 & 依赖注入的惊喜

这周在学习设计模式，尤其是 依赖注入，感觉特别顺手：不用自己管理依赖，需要什么就拿什么。

我也把笔记整理了一下，链接放这：

生活：武汉三日游 + 北京小打卡

武汉三日游（周五晚 ~ 周一）

请了一天假去武汉，天气真的是 大蒸炉：又热又闷还下雨 (；´д｀)ゞ。不过吃的还不错，烤鱼很香（忘记吃火锅了，下次补上）。

北京周末小逛

这周末去国贸转了一下，来北京半年了还没怎么逛。打卡了 offer 大楼（许愿 offer (☆_☆)），还有大裤衩和中央广播电视中心。

南锣鼓巷像个小吃街，胡同文化是不是就是夜市小吃街（？）。还打卡了 黄仁勋同款蜜桃四季春。

最后去了什刹海和北海公园，北京的“海”确实挺好看。

碎碎念

他们怎么周五都团建……我们组呢？为什么只有闷头干活 (눈_눈)。

总之，这两周虽然累，但感觉自己对“混研 + 低代码 + 发布链路”这条线越来越熟了。希望携程面试能过，换个环境好好准备秋招。

一点思考

这两周的感受挺现实：业务需求不会因为你迷茫就暂停，线上问题也不会因为你累就不来。但好的一面是，每一次“被迫修复”和“被迫适配”，都在逼着我把能力拼成闭环——从定位问题、理解链路、改完上线，再到写文档沉淀。

当情绪很乱的时候，我会提醒自己：先把能掌控的事情做好。能做的，就是把当下的事情做到更扎实，把每一次坑踩成一条清晰的路。路会慢，但路是往前的。

“路漫漫其修远兮，吾将上下而求索。”——屈原

下周继续努力，愿 offer 来得更猛一点 (ง •_•)ง

设计模式：创建型模式

Sun, 31 May 2026 12:00:00 GMT

创建型模式到底在解决什么？

创建型模式的核心，不是“发明几个高大上的名词”，而是把对象创建这件事从业务代码里收回来，交给一个更稳定、更统一的地方处理。

如果你到处都是 new Xxx()，对象的创建方式、参数变化、依赖顺序一改，整个项目都会跟着震动。创建型模式本质上就是在降低这种“创建方式变化”带来的耦合。

一句话总结

“怎么创建对象”这件事，和“怎么使用对象”分开。

工厂模式（Factory Pattern）

前端真实场景：根据数据动态渲染不同卡片

在富文本编辑器、低代码平台、CMS 页面里，经常会遇到这种场景：后端返回一个 type，你要根据 type 渲染不同组件。

比如后端接口真实返回的一份页面区块数据可能是这样的：

{
  "id": "block_9527",
  "type": "video",
  "properties": {
    "src": "https://example.com/movie.mp4",
    "autoplay": true,
    "controls": false
  },
  "layout": {
    "width": "100%",
    "marginTop": "20px"
  }
}

面对这种数据，我们很多人的第一反应就是在业务层直接写一长串的 if / else 或者 switch，即：把“判断类型、收集参数、实例化核心类”这三件事揉在一起。

一段不假思索的、高度耦合的渲染逻辑大概率会长这样：

// 假设这些是我们底层依赖的第三方或自己写的复杂组件类
import { VideoPlayer, ImageViewer, TextRender } from "@/libs/ui-core";

function renderBlock(blockData: any) {
  //  耦合发生地：需要关心要 new 谁，还要关心每个类初始化需要怎么塞参数
  if (blockData.type === "video") {
    const player = new VideoPlayer({
      url: blockData.properties.src,
      auto: blockData.properties.autoplay,
      showControls: blockData.properties.controls,
    });
    player.setStyle(blockData.layout);
    return player.mount();
  } else if (blockData.type === "image") {
    const viewer = new ImageViewer(blockData.properties.src);
    viewer.setStyle(blockData.layout);
    return viewer.mount();
  } else if (blockData.type === "text") {
    const textNode = new TextRender(blockData.properties.content);
    textNode.setStyle(blockData.layout);
    return textNode.mount();
  }

  throw new Error("未知的区块类型");
}

这里的问题很快就暴露出来了：renderBlock 这个普通的业务视图函数，背负了太多。它既负责“判断结构”，又负责“去调底层的各种类”，还负责“拼装特定的参数和样式”。一旦新增一个 quote 引用类型，或者大版本更新 VideoPlayer 的构造函数的入参变了，这个函数就得跟着大改。

如果没有工厂，灾难还会蔓延

如果上面这段逻辑只在一个地方写还能忍，但往往这些底层实体类需要在多个位置被实例化。比如 Toolbar、快捷键、右键菜单里都可能需要凭空生成一个视频块。

没有工厂时，业务组件会自己决定“创建谁、怎么创建、参数怎么传”，于是每个文件里都开始写同样的实现：

// Toolbar.vue
const block = blockType === "video"
    ? new VideoPlayer({ /* 传一堆参 */ })
    : blockType === "image"
      ? new ImageViewer(/* 传参数 */)
      : new TextRender(/* 传参数 */);

// Shortcut.vue
const block = blockType === "video" ? new VideoPlayer({ /* ... */ }) : /* ... */

// RightMenu.vue
const block = blockType === "video" ? new VideoPlayer({ /* ... */ }) : /* ... */

这会带来两个绝望的问题：

创建逻辑散落到处都是。以后 VideoPlayer 构造函数多一个必填参数，你要全局搜索这十几个文件，挨个 new VideoPlayer(...) 去改，直接崩溃。
业务组件被创建细节绑死。组件本来只该关心“我要一个卡片”，结果被迫知道了“底层的某个卡片到底是怎么造出来的和需要什么格式的参数”。

更前端一点的写法：工厂模式解耦

工厂模式的核心，就是建一个专门用来“制造对象”的工厂。业务层只管提交“加工单”，工厂负责查参数、分配给具体类。

import { VideoPlayer, ImageViewer, TextRender } from "@/libs/ui-core";

//  创建一个专门的制造工厂
export class BlockFactory {
  static create(blockData: any) {
    let instance;
    switch (blockData.type) {
      case "video":
        instance = new VideoPlayer({
          url: blockData.properties.src,
          auto: blockData.properties.autoplay,
          showControls: blockData.properties.controls,
        });
        break;
      case "image":
        instance = new ImageViewer(blockData.properties.src);
        break;
      case "text":
        instance = new TextRender(blockData.properties.content);
        break;
      default:
        throw new Error(`不支持的类型: ${blockData.type}`);
    }

    // 统一处理公共逻辑，比如样式挂载
    if (blockData.layout && instance.setStyle) {
      instance.setStyle(blockData.layout);
    }

    return instance;
  }
}

调用方的世界彻底清爽了：

// renderBlock.ts 或者是 Vue组件内部
import { BlockFactory } from "./BlockFactory";

function renderBlock(blockData: any) {
  // 业务层再也不用关心到底 new 了什么、传了什么细节散参
  const block = BlockFactory.create(blockData);
  return block.mount();
}

这样后续如果新增 QuoteCard，你只需改且只改 BlockFactory 一个文件即可，其它业务层逻辑纹丝不动。

单例模式（Singleton Pattern）

前端真实场景：全局唯一的 WebSocket 消息通知

假设我们在做一个有很多页面的管理系统，几乎每个页面（顶部的未读消息红点、侧边栏的审批通知、甚至弹窗里）都需要实时接收后端的 WebSocket 消息。

第一反应：哪里需要，就在哪里连

最直白的写法就是，我们在 Header.vue 和 Sidebar.vue 里各自去建立连接：

// Header.vue
const ws = new WebSocket("wss://api.example.com/notifications");
ws.onmessage = (msg) => {
  console.log("更新顶部红点", msg);
};

// Sidebar.vue
const ws = new WebSocket("wss://api.example.com/notifications");
ws.onmessage = (msg) => {
  console.log("更新侧边栏待办", msg);
};

灾难：服务器爆炸与状态非同步

如果真的这么写，会带来非常恐怖的灾难：

资源极度浪费：用户打开一个页面，前端悄悄建立了 5 个 WebSocket 连接，后端连接数直接原地爆炸。
数据不同步：不同组件各自维系一个连接，由于网络延迟，顶部已经显示有新消息，侧边栏还是旧的。

解决思路：单例模式

单例的核心就是 “计划生育”，保证一个类在整个运行周期里，绝对只有唯一的一个实例。如果是第一次要，我就建给你；如果已经建过了，我就把之前那个给你。

经典的类实现方法（通过类的静态属性拦截）：

export class WsManager {
  // 1. 静态属性存放唯一实例
  private static instance: WsManager | null = null;
  public ws: WebSocket;

  // 2. 构造函数私有化，防死外部 new WsManager()
  private constructor() {
    this.ws = new WebSocket("wss://api.example.com/notifications");
  }

  // 3. 唯一的获取入口
  public static getInstance() {
    if (!WsManager.instance) {
      WsManager.instance = new WsManager();
    }
    return WsManager.instance;
  }
}

// 后续在任何地方获取，拿到的都是同一个连接内存地址
const ws1 = WsManager.getInstance();
const ws2 = WsManager.getInstance();
console.log(ws1 === ws2); // true

更现代的前端做法（ES Module 就是天然的单例）： 如今在前端，打包工具自带模块缓存，我们根本不需要写那么绕的类代码。

// wsManager.ts
// 文件只会被解析执行一次，天然保证单例
export const globalWs = new WebSocket("wss://api.example.com/notifications");

到处 import { globalWs } from './wsManager' 即可。

依赖注入（Dependency Injection, DI）

前端真实场景：深层级组件的上下文传递

假设你的整个系统支持“暗黑/明亮”主题切换，并且内部有一套极端复杂的多级表单。结构是这样的：App -> Layout -> Page -> Table -> Form -> Button。最底层的 Button 按钮需要知道当前的 theme 来决定自己的背景色。

第一反应：Props 一路向下钻（Props Drilling）

最朴素的想法：既然数据在最顶层的 App.vue，我就一层层用 Props 传下去。

<!-- App.vue -->
<Layout :theme="currentTheme" />

<!-- Layout.vue -->
<Page :theme="props.theme" />

<!-- Page.vue -->
<Table :theme="props.theme" />

<!-- ... 一直传到 Button.vue -->

灾难：无辜的中间层被绑架

这种写法叫 props drilling（属性钻取）。

中间组件被污染：Page 和 Table 从头到尾都没用到 theme，但它们被迫在代码里声明并传递这个变量。代码又臭又长。
高度耦合，难以复用：如果你想把 Table 组件移植到另一个没有 theme 设定的项目里，它竟然会报错说少传了参数。

解决思路：依赖注入（DI）

依赖注入的精髓是：最底层不用去问上层要，也不用自己想办法新建；顶层直接把东西“注入”到一个公共的空气通道里，底层直接“伸手拿”。

在 Vue 3 里，这就是最经典的 provide / inject：

顶层提供依赖（Provide）：

<!-- App.vue (提供方) -->
<script setup>
import { provide, ref } from "vue";

const currentTheme = ref("dark");
// 把依赖注入到这棵组件树的虚拟空间中
provide("app-theme", currentTheme);
</script>

底层无脑获取（Inject）：

<!-- Button.vue (任意深的子组件) -->
<script setup>
import { inject } from "vue";

// 绕过所有中间层，直接伸手拿
const theme = inject("app-theme", "light" /* 默认值 */);
</script>

<template>
  <button :class="`btn-${theme}`">提交</button>
</template>

中间的 Layout, Page, Table 再也不需要碰 theme 这个雷区了，这也就是所谓**“控制反转（IoC）”**在组件层的最佳体现。

进阶前端场景：逻辑类的连环依赖（A 依赖 B，B 依赖 C）

在前端的复杂单页应用中，我们的网络请求模块（Service / API 抽象层）往往存在这种连环依赖：我们要写一个 UserService 请求用户数据；发请求前拿 Token 需要经过 AuthService 鉴权；而 AuthService 又必须依赖 StorageService 去读取底层的 localStorage。

如果按照传统直觉去写（强耦合的层层 import 和 new）：

// StorageService.ts
export class StorageService {
  /* 读写底层缓存 */
}

// AuthService.ts
import { StorageService } from "./StorageService";

export class AuthService {
  storage: StorageService;
  constructor() {
    //  灾难1：强行在此处实例化了底层的具体实现
    this.storage = new StorageService();
  }
}

// UserService.ts
import { AuthService } from "./AuthService";

export class UserService {
  auth: AuthService;
  constructor() {
    //  灾难2：继续俄罗斯套娃
    this.auth = new AuthService();
  }
}

(注：上面这种写法，导致 UserService、AuthService 和 StorageService 三者这辈子彻底焊死了。这会带来无尽的折磨，比如你要给 UserService 写隔离单元测试时，它会一路顺藤摸瓜去读真实的缓存 API，直接引发环境报错；一旦 StorageService 构造函数需要加一个配置参数，你要去所有 new StorageService 的上游文件里挨个改代码！)

终极解决思路：IoC 容器统一做这层“中间商”

我们在 Angular、InversifyJS（或后端的 NestJS）中见到的 DI，正是通过IoC 容器来彻底接管这一切。它的精髓是：你不准在 A 里面再去 import B 然后 new B() 了。需要依赖的类都在头上打个标签（@Injectable），大家只需要通过构造函数大喊“我要什么包”，剩下的一切统统交给“容器管家”去自动管理。

import { Injectable, Container } from "di-library";

@Injectable()
class StorageService {}

@Injectable()
class AuthService {
  // 告诉管家：我需要一个 StorageService 实例，不用我自己 new，请派发给我
  constructor(private storage: StorageService) {}
}

@Injectable()
class UserService {
  // 告诉管家：我需要一个 AuthService 实例
  constructor(private auth: AuthService) {}
}

//  见证奇迹的时刻
const container = new Container();

// 业务端只管“伸手要”，拿到的就是配置好一切的完整对象：
const userService = container.get(UserService);

在这个过程中，容器（Container）在底层偷偷帮你完成了一张依赖拓扑图：它看到你想要 UserService，但发现缺 AuthService，再去查发现还缺 StorageService。于是管家默默地帮你执行： new StorageService() -> 把缓存实例塞给 new AuthService(...) -> 最后把 auth 实例塞给 new UserService(...)。

这就是 DI 最爽的地方：你只需要拿，不需要管。 至于 C 怎么实例化的、B 的参数怎么来的？全部由统一的容器从上帝视角帮你构建好，我们再也不用手动去层层依赖、层层瞎改代码了。

附录：这个“管家”底层凭什么这么神奇？（极简版容器实现）

其实 IoC 容器没有魔法，它的核心本质就是一个注册表（Map）再加上递归实例化。借此机会，我们可以用十几行代码自己手写一个极简版的 Container，一看就懂：

class Container {
  // 核心：一个存放所有信息的大字典
  private registry = new Map();

  // 1. 登记办事处：把类和它需要的依赖存进来
  register(name: string, ClassRef: any, dependencies: string[] = []) {
    this.registry.set(name, { ClassRef, dependencies });
  }

  // 2. 核心大招：顺藤摸瓜，递归提车
  get(name: string) {
    const target = this.registry.get(name);
    if (!target) throw new Error(`${name} 还未注册`);

    // 递归去拿所有的依赖（如果依赖还有依赖，就继续向下挖）
    const resolvedDeps = target.dependencies.map((depName) =>
      this.get(depName),
    );

    // 把查到的所有依赖实例，当成参数原封不动地丢进构造函数！
    return new target.ClassRef(...resolvedDeps);
  }
}

// ============ 测试一下 ============
const container = new Container();

// 提前告诉管家：他们分别是谁，依赖什么？
container.register("Storage", StorageService);
container.register("Auth", AuthService, ["Storage"]); // Auth需要Storage
container.register("User", UserService, ["Auth"]); // User需要Auth

// 业务端发话了：管家，把你弄好的 User 给我！
const user = container.get("User");
// 管家收到：发车！内部自动执行了 get('Auth') -> get('Storage') 帮你 new 到底！

(注：真实的 InversifyJS 或 Angular 容器比这更强大，它们能缓存实例（即单例模式），而且借助 TypeScript 的 @Injectable() 装饰器和 reflect-metadata，它内部能自动读取到你的构造函数里写了什么类型，你甚至连 ['Storage'] 这种依赖名字都不需要手写了！)

原型模式（Prototype Pattern）

前端真实场景：满地都是的臃肿图表配置

我们在做后台大屏时，往往需要用到 ECharts。一个 ECharts 的 option 配置对象通常长达上百行，包括标题、图例、网格、提示框、X 轴、Y 轴等等。现在一屏里要画 5 个图表（4 个折线图，1 个柱状图），长得几乎一模一样，只有数据不同。

第一反应：疯狂复制粘贴字典对象

// 图表A
const chartAOption = {
  title: { text: "销量" },
  tooltip: { trigger: "axis" },
  grid: { left: "3%", right: "4%", bottom: "3%", containLabel: true },
  xAxis: { type: "category" },
  yAxis: { type: "value" },
  series: [{ type: "line", data: [120, 200, 150] }],
};

// 图表B（直接把上面那一大坨复制过来改改数据）
const chartBOption = {
  title: { text: "访客" },
  tooltip: { trigger: "axis" },
  grid: { left: "3%", right: "4%", bottom: "3%", containLabel: true },
  xAxis: { type: "category" },
  yAxis: { type: "value" },
  series: [{ type: "line", data: [800, 900, 700] }],
};

灾难：一处 UI 改动，处处漏改

代码极度膨胀：5 个图表，500 行代码，翻都翻不到底。
维护噩梦：产品经理说“把图表边距 bottom 从 3% 统一改成 5%”。你得在成堆的代码里挨个 Ctrl+F 去找 grid 属性。万一漏改了哪怕一个，界面就出现了不对齐。

解决思路：原型模式

原型模式的本质：先捏一个尽量完美的“泥人（模板）”，后面全靠这个泥人“克隆（拷贝）”，只对克隆体做微调。

通过 Object.create 或 structuredClone（深拷贝）：

//  先定一个“原生泥人”（Base 原型）
const baseChartContext = {
  tooltip: { trigger: "axis" },
  grid: { left: "5%", right: "4%", bottom: "5%", containLabel: true },
  xAxis: { type: "category" },
  yAxis: { type: "value" },
};

//  接下来全靠拷贝微调
const chartAOption = structuredClone(baseChartContext);
chartAOption.title = { text: "销量" };
chartAOption.series = [{ type: "line", data: [120, 200, 150] }];

const chartBOption = structuredClone(baseChartContext);
chartBOption.title = { text: "访客" };
chartBOption.series = [{ type: "line", data: [800, 900, 700] }];

边距怎么改？只改 baseChartContext 那一个地方，瞬间生效全场。

建造者模式（Builder Pattern）

前端真实场景：复杂的弹窗参数 / 动态查询 API

写中后台列表页的请求时，我们需要处理一系列复杂的查询条件（关键词、页码、条数、状态枚举、时间范围、排序字段）。

第一反应：塞出一个无敌长的参数列表

function fetchTableData(
  keyword: string,
  page: number,
  size: number,
  status?: number,
  startDate?: string,
  endDate?: string,
  sortBy?: string,
) {
  // 一大坨拼 url 的逻辑
}

//  业务里调用时，场面极其惨烈：
fetchTableData("apple", 1, 20, undefined, undefined, undefined, "price");

或者稍微好一点，封装成一个大 Object：

fetchTableData({
  keyword: "apple",
  page: 1,
  size: 20,
  sortBy: "price",
});

但这还是没解决组装条件时，大量的判空逻辑散布在业务组件中的问题。

灾难：极差的可读性与扩展逻辑的散落

一旦我们需要根据用户点击不同的选项，渐进式地往里加参数（先设了时间，再设了状态，最后才点击发送），大参数对象会被传来传去，谁都可以在中途直接 params.status = 1 把它修改掉。哪天查不出数据了，你完全不知道参数是在哪一行被破坏的。

解决思路：建造者模式

建造者模式的思想是：把一个复杂对象的创建过程“碎片化、流水线化”，通过链式调用，一步一步地把它“建造”出来，最后再出厂（build）。

//  创建一个查询条件的“施工队”
class QueryBuilder {
  private params: Record<string, any> = { page: 1, size: 20 };

  // 各种 set 方法，总是 return this 以实现链式调用
  setKeyword(word: string) {
    if (word) this.params.keyword = word;
    return this;
  }
  setPaging(page: number, size: number) {
    this.params.page = page;
    this.params.size = size;
    return this;
  }
  setDateRange(start?: string, end?: string) {
    if (start && end) {
      this.params.startDate = start;
      this.params.endDate = end;
    }
    return this;
  }

  //  最后一道工序：出厂
  build() {
    return this.params;
  }
}

有了它，业务代码的可读性直线上升：

const finalParams = new QueryBuilder()
  .setKeyword("apple")
  .setPaging(1, 20)
  .setDateRange("2026-05-01", "2026-05-31")
  .build();

axios.get("/api/goods", { params: finalParams });

不光优雅，还在内部消灭了烦穿人的 if (xxx !== undefined)。

对象池模式（Object Pool）

前端真实场景：满屏的春节红包雨 / Canvas 子弹效果

在做双十一大促的“金币雨”特效，或者 Canvas 网页游戏里的机枪扫射时，屏幕上短时间内会出现成百上千个不断下落又消失的元素。

第一反应：疯狂创建与销毁 DOM / 对象

// 每 10 毫秒就 new 一枚新金币
setInterval(() => {
  const coin = new CoinNode();
  document.body.appendChild(coin.el);

  // 下落 3 秒后销毁
  setTimeout(() => {
    coin.el.remove();
    coin.destroy();
  }, 3000);
}, 10);

灾难：GC（垃圾回收）榨干了浏览器性能

在 V8 引擎（浏览器底层）里，创建对象要申请内存，销毁对象需要等待 Garbage Collection 去清理。如果你每秒创建 100 个金币，同时又有一堆金币销毁，GC 就会疯狂启动。GC 启动时会阻塞主线程（Stop-the-world），进而导致你的动画出现肉眼可见的“卡顿、掉帧”。

解决思路：对象池模式

对象池不算是经典 GoF 的 23 种设计模式，却是前端渲染（不仅是 DOM，包括 WebGL）优化的神兵利器。核心思想：像图书馆借书一样。提前造好一堆对象放在池子里。要用就“借”，用完“隐藏并还”回池子，绝不销毁。

class CoinPool {
  private pool: CoinNode[] = [];

  // 1. 初始化时，直接造 50 个隐藏的硬币塞进池子
  constructor(size = 50) {
    for (let i = 0; i < size; i++) {
      const coin = new CoinNode();
      coin.hide();
      this.pool.push(coin);
    }
  }

  // 2. 借出：不 new，直接从池子里捞一个闲置的拿去复用
  acquire(): CoinNode {
    // 找到还在池子里的硬币推出
    const coin = this.pool.pop();
    if (coin) return coin;

    // 实在不够了再补 new
    return new CoinNode();
  }

  // 3. 归还：隐藏，坐标归零，塞回池子接着等下一波
  release(coin: CoinNode) {
    coin.hide();
    coin.resetPosition();
    this.pool.push(coin);
  }
}

业务端逻辑：

const pool = new CoinPool(100); // 先备好 100 发子弹

setInterval(() => {
  const coin = pool.acquire(); // 借用
  coin.startFalling();

  setTimeout(() => {
    pool.release(coin); // 落下去了？回收！下一波接着用它。
  }, 3000);
}, 10);

通过这种方式，动画全程没有任何一个对象被销毁，GC 彻底处于休眠状态，帧率稳如老狗。

总结：创建型模式到底在帮你什么？

把这几种模式放在一起看，它们其实都在做一件事：削弱“创建细节”对业务代码的污染。

模式	重点	解决什么耦合
工厂模式	统一创建入口	业务代码判断繁琐、不再到处 `new`
单例模式	全局唯一实例	避免各种重复创建连累性能与状态不同步
依赖注入	外部提供依赖	对具体实现的硬绑定，组件树中间层惨遭连累
原型模式	基于模板复制	一大坨 JSON 对象重复写，改一次漏五次
建造者模式	分步骤打磨	发请求、构造复杂对象时可恶的大参数列表和判空
对象池模式	借出与回收	高频创建销毁导致的 GC 掉帧与页面卡死

最后用一句前端味更重的话收尾

如果一个组件一旦写进去，就必须知道“底层对象怎么造、深渊依赖怎么来、几百行配置怎么拼、渲染实例怎么销毁”，那这个组件就已经过度耦合了。

创建型模式要做的，就是把这些脏活从你的 Vue/React 业务代码里拿走。 把“该谁管”划清楚，让组件专心画 UI，让创建的烂摊子交给专门的人去处理。

设计模式：行为型模式

Sun, 31 May 2026 11:50:35 GMT

行为型模式到底在解决什么？

行为型模式关注的不是“对象怎么来”，而是“对象怎么协作、怎么流转、怎么把行为拆开”。前端常见的状态切换、事件联动、流程编排，往往都藏着行为型模式的影子。

它的本质是：把变化的行为从业务代码里抽出来，让流程不再被一堆 if / else 驱动，而是被更清晰、更可替换的规则驱动。

一句话总结

“谁来驱动流程 / 谁来响应变化”这件事，从业务里抽出来。

发布订阅模式（Publish-Subscribe / Observer Pattern）

前端真实场景：跨组件事件通知（Vue2 $bus → Vue3 单向数据流）

从 Vue2 的 $bus 到 Vue3 的 emit，发布订阅几乎是前端最熟的模式。Vue3 不再推荐 $bus，是因为它强化了单向数据流：数据向下、事件向上。

第一反应：上一个全局事件总线

// Vue2 时代常见写法
const bus = new Vue();

// A.vue
bus.$emit("user:login", user);

// B.vue
bus.$on("user:login", (u) => {
  userStore.set(u);
});

灾难：事件飞来飞去，谁也不负责

事件名冲突：全局事件越来越多，改一个名字会牵一堆文件。
流向不可追踪：谁 emit，谁监听，谁清理，完全失控。
监听泄漏：组件卸载后忘记 off，事件继续触发。

解决思路：手撕发布订阅 + 限定边界

type Handler = (payload?: any) => void;

class PubSub {
  // eventName -> handlers
  private events: Record<string, Set<Handler>> = {};

  on(event: string, handler: Handler) {
    // 订阅：返回取消函数
    if (!this.events[event]) this.events[event] = new Set();
    this.events[event].add(handler);
    return () => this.off(event, handler);
  }

  once(event: string, handler: Handler) {
    // 只触发一次
    const off = this.on(event, (payload) => {
      off();
      handler(payload);
    });
    return off;
  }

  off(event: string, handler: Handler) {
    // 取消订阅
    this.events[event]?.delete(handler);
  }

  emit(event: string, payload?: any) {
    // 发布事件
    this.events[event]?.forEach((handler) => handler(payload));
  }
}

// 只在“认证模块”内部共享，而不是全局总线
const authBus = new PubSub();

export const onLogin = (fn: Handler) => authBus.on("login", fn);
export const emitLogin = (user: { id: string; name: string }) =>
  authBus.emit("login", user);

发布订阅可以用，但必须有边界。组件内优先 props + emit，跨模块再用模块级事件中心或状态库。

策略模式（Strategy Pattern）

前端真实场景：不同会员等级的定价策略

会员、渠道、节日折扣一多，价格计算就会变成一坨 if/else。这类“规则变化频繁”的场景，就是策略模式的主场。

第一反应：条件分支写到天荒地老

function calcPrice(plan: string, base: number) {
  if (plan === "free") return base;
  if (plan === "vip") return base * 0.9;
  if (plan === "svip") return base * 0.8;
  return base;
}

灾难：新增一个策略等于改核心逻辑

分支越来越长：新增“学生价 / 员工价”就得改核心函数。
测试负担飙升：每次新增都要回归所有分支。

解决思路：策略对象化，Context 执行策略

type PricingContext = {
  coupon?: number;
};

interface PricingStrategy {
  // 每个策略只实现自己的算法
  algorithm(base: number, ctx: PricingContext): number;
}

class FreeStrategy implements PricingStrategy {
  algorithm(base: number, ctx: PricingContext) {
    // 免费会员不打折，保留优惠券
    return base - (ctx.coupon ?? 0);
  }
}

class VipStrategy implements PricingStrategy {
  algorithm(base: number, ctx: PricingContext) {
    // VIP 9 折
    return base * 0.9 - (ctx.coupon ?? 0);
  }
}

class SvipStrategy implements PricingStrategy {
  algorithm(base: number, ctx: PricingContext) {
    // SVIP 8 折
    return base * 0.8 - (ctx.coupon ?? 0);
  }
}

class PricingContextExecutor {
  // Context 持有策略，可动态替换
  constructor(private strategy: PricingStrategy) {}

  setStrategy(strategy: PricingStrategy) {
    this.strategy = strategy;
  }

  executeStrategy(base: number, ctx: PricingContext) {
    // 对外统一入口
    return this.strategy.algorithm(base, ctx);
  }
}

const context = new PricingContextExecutor(new VipStrategy());
const price = context.executeStrategy(200, { coupon: 20 });

策略模式把“变化点”集中到策略里，Context 只负责执行。

状态模式（State Pattern）

前端真实场景：支付按钮的状态流转

一个“立即支付”按钮背后有明确状态：idle → paying → success / failed。没有状态机，按钮逻辑很快就变成“全靠人脑记忆”。

第一反应：用多个布尔值硬撑

const state = {
  isPaying: false,
  isSuccess: false,
  isFailed: false,
};

灾难：非法组合 + 分支爆炸

状态互相打架：isPaying 和 isSuccess 可能同时为 true。
按钮文案失控：有人忘了更新 disabled，导致重复下单。

解决思路：用状态机约束“能做什么”

type PayState = "idle" | "paying" | "success" | "failed";
type PayAction = "submit" | "resolve" | "reject" | "reset";

// 状态转移表：只允许合法流转
const transitions: Record<PayState, Partial<Record<PayAction, PayState>>> = {
  idle: { submit: "paying" },
  paying: { resolve: "success", reject: "failed" },
  success: { reset: "idle" },
  failed: { reset: "idle" },
};

// UI 映射表：状态决定渲染
const viewState: Record<PayState, { text: string; disabled: boolean }> = {
  idle: { text: "立即支付", disabled: false },
  paying: { text: "支付中...", disabled: true },
  success: { text: "支付成功", disabled: true },
  failed: { text: "支付失败，重试", disabled: false },
};

let state: PayState = "idle";

function dispatch(action: PayAction) {
  // 通过状态转移表推进
  state = transitions[state][action] ?? state;
  // 状态变化驱动 UI
  render(viewState[state]);
}

状态机让“什么时候能做什么”变成规则，而不是临时约定。

责任链模式（Chain of Responsibility Pattern）

前端真实场景：请求链路的多级处理

请求出去之前要鉴权、签名、缓存命中、重试，甚至还要打点上报。每一步都可能“截断流程”。

第一反应：把所有判断塞进一个函数

async function handleRequest(ctx: any) {
  if (!ctx.token) throw new Error("unauthorized");
  if (ctx.isBlocked) throw new Error("blocked");
  if (ctx.useCache) return ctx.cache;
  return fetch(ctx.url);
}

灾难：一条链条绑死所有规则

强耦合：规则必须按固定顺序执行。
不可复用：不同模块想改顺序或省略某一步都要改源码。

解决思路：把规则拆成可插拔的链

type Context = {
  req: Request;
  token?: string;
  response?: Response;
};

type Middleware = (ctx: Context, next: () => Promise<void>) => Promise<void>;

const compose = (middlewares: Middleware[]) => {
  return (ctx: Context) => {
    let index = -1;
    const dispatch = (i: number): Promise<void> => {
      // next 只能被调用一次
      if (i <= index) return Promise.reject(new Error("next called twice"));
      index = i;
      const fn = middlewares[i];
      if (!fn) return Promise.resolve();
      // 把控制权交给下一个 handler
      return fn(ctx, () => dispatch(i + 1));
    };
    return dispatch(0);
  };
};

const withAuth: Middleware = async (ctx, next) => {
  // 鉴权拦截
  if (!ctx.token) throw new Error("unauthorized");
  // 统一塞 token
  ctx.req.headers.set("Authorization", `Bearer ${ctx.token}`);
  await next();
};

const withCache: Middleware = async (ctx, next) => {
  // 命中缓存则直接返回
  const cached = await readCache(ctx.req);
  if (cached) {
    ctx.response = cached;
    return;
  }
  await next();
  // 回写缓存
  if (ctx.response) await writeCache(ctx.req, ctx.response);
};

const withRetry: Middleware = async (ctx, next) => {
  // 重试三次
  for (let i = 0; i < 3; i += 1) {
    try {
      await next();
      return;
    } catch (err) {
      // 最后一次才抛出
      if (i === 2) throw err;
    }
  }
};

const fetcher: Middleware = async (ctx) => {
  // 真正发请求
  ctx.response = await fetch(ctx.req);
};

const chain = compose([withAuth, withCache, withRetry, fetcher]);
await chain({ req: new Request("/api/order"), token: "t1" });

每个规则独立、顺序可换，这就是责任链的价值。

命令模式（Command Pattern）

前端真实场景：画布编辑器的撤销/重做

拖拽、对齐、改名、删除……这些操作都需要“可撤销”。如果直接改数据，历史就很难还原。

第一反应：直接改模型

layers[index].name = "Banner";

灾难：历史被打碎，撤销无从下手

操作不可逆：改了就改了，回不去。
重做体系缺失：撤销后再操作，历史乱成一团。

解决思路：把操作封装为命令

interface Command {
  // 执行与撤销
  execute(): void;
  undo(): void;
}

class CommandManager {
  // 维护撤销/重做栈
  private undoStack: Command[] = [];
  private redoStack: Command[] = [];

  execute(cmd: Command) {
    // 执行后写入撤销栈
    cmd.execute();
    this.undoStack.push(cmd);
    // 新操作会清空重做栈
    this.redoStack = [];
  }

  undo() {
    const cmd = this.undoStack.pop();
    if (!cmd) return;
    cmd.undo();
    this.redoStack.push(cmd);
  }

  redo() {
    const cmd = this.redoStack.pop();
    if (!cmd) return;
    cmd.execute();
    this.undoStack.push(cmd);
  }
}

class MoveLayerCommand implements Command {
  constructor(
    private layer: any,
    private from: { x: number; y: number },
    private to: { x: number; y: number },
  ) {}
  execute() {
    // 执行移动
    this.layer.x = this.to.x;
    this.layer.y = this.to.y;
  }
  undo() {
    // 撤销移动
    this.layer.x = this.from.x;
    this.layer.y = this.from.y;
  }
}

const manager = new CommandManager();
manager.execute(new MoveLayerCommand(layer, { x: 0, y: 0 }, { x: 120, y: 40 }));
manager.undo();

命令模式让“操作”变成对象，撤销/重做变成基础能力。

模板方法模式（Template Method Pattern）

前端真实场景：列表页加载流程高度一致

列表页几乎都在做同一件事：loading → 拉数据 → 归一化 → 渲染 → 错误处理 → 打点。

第一反应：每个页面都写一套流程

setLoading(true);
try {
  const raw = await fetchList();
  const data = normalize(raw);
  setList(data);
  report("list_loaded");
} catch (err) {
  toast("加载失败");
} finally {
  setLoading(false);
}

灾难：重复 + 不一致

逻辑重复：每个页面一套“loading + error”。
细节不一致：有的页面没打点，有的页面没兜底。

解决思路：固定骨架，差异留给子类

abstract class BaseListLoader<T> {
  async load() {
    // 模板方法：固定流程骨架
    this.before();
    try {
      const raw = await this.fetch();
      const data = this.normalize(raw);
      this.after(data);
      return data;
    } catch (err) {
      // 统一错误处理入口
      this.onError(err);
      throw err;
    } finally {
      // 统一收尾入口
      this.finally();
    }
  }
  protected before() {}
  protected after(_data: T[]) {}
  protected onError(_err: unknown) {}
  protected finally() {}
  protected abstract fetch(): Promise<any>;
  protected abstract normalize(raw: any): T[];
}

class UserListLoader extends BaseListLoader<User> {
  protected before() {
    // 钩子：loading
    setLoading(true);
  }
  protected fetch() {
    // 钩子：拉数据
    return http.get("/api/users");
  }
  protected normalize(raw: any) {
    // 钩子：格式归一化
    return raw.data;
  }
  protected after() {
    // 钩子：打点
    report("user_list_loaded");
  }
  protected onError() {
    // 钩子：错误提示
    toast("加载失败");
  }
  protected finally() {
    // 钩子：收尾
    setLoading(false);
  }
}

骨架流程稳定，差异逻辑只需要覆盖少量钩子。

迭代器模式（Iterator Pattern）

前端真实场景：统一遍历路由树与权限树

路由树、菜单树、权限树本质都是树。遍历逻辑散落在业务里，会导致“每个模块写一套递归”。

第一反应：每次都手写递归

function walk(node: any) {
  node.children?.forEach(walk);
  doSomething(node);
}

灾难：遍历规则不统一

先序/后序各写一套：不同模块遍历顺序不一致。
难以复用：过滤、聚合、统计都要重复造轮子。

解决思路：把遍历变成可迭代协议

type RouteNode = {
  path: string;
  meta?: { hidden?: boolean };
  children?: RouteNode[];
};

function* traverse(nodes: RouteNode[]): Generator<RouteNode> {
  // 先序遍历
  for (const node of nodes) {
    yield node;
    if (node.children) yield* traverse(node.children);
  }
}

class RouteTree implements Iterable<RouteNode> {
  constructor(private roots: RouteNode[]) {}
  [Symbol.iterator]() {
    // 让树可迭代
    return traverse(this.roots);
  }
}

const tree = new RouteTree(routes);

const visiblePaths = [];
for (const node of tree) {
  // 业务侧只关心“拿到节点”
  if (!node.meta?.hidden) visiblePaths.push(node.path);
}

迭代器让遍历方式可复用，业务只管消费节点。

备忘录模式（Memento Pattern）

前端真实场景：复杂表单的“撤销修改/恢复草稿”

表单字段多、逻辑多时，经常要“回到上一步”或者“恢复到上次保存”。如果直接拿着业务对象硬改，就很难回退。

第一反应：每次改动都深拷贝一份

history.push(JSON.parse(JSON.stringify(formState)));

灾难：内存暴涨 + 回退难以控制

全量拷贝成本高：字段一多，拷贝与存储都顶不住。
回退粒度混乱：什么时候保存、保存几份，全靠人记。

解决思路：把“状态快照”抽成备忘录

type Draft = {
  title: string;
  content: string;
  tags: string[];
};

class DraftMemento {
  // 快照对象（只读）
  constructor(public readonly state: Draft) {}
}

class DraftOriginator {
  constructor(private state: Draft) {}

  setState(next: Draft) {
    // 修改业务状态
    this.state = next;
  }

  createMemento() {
    // 生成快照
    return new DraftMemento({ ...this.state, tags: [...this.state.tags] });
  }

  restore(memento: DraftMemento) {
    // 恢复快照
    this.state = { ...memento.state, tags: [...memento.state.tags] };
  }

  getState() {
    // 对外读取当前状态
    return this.state;
  }
}

const originator = new DraftOriginator({ title: "", content: "", tags: [] });
// caretaker：维护快照历史
const history: DraftMemento[] = [];

history.push(originator.createMemento());
originator.setState({ title: "草稿 A", content: "内容", tags: ["vue"] });

const last = history.pop();
if (last) originator.restore(last);

备忘录把“保存/恢复”变成显式动作，撤销逻辑就有了抓手。

中介者模式（Mediator Pattern）

前端真实场景：筛选面板的联动逻辑

品牌、价格区间、库存状态、促销标签之间经常互相影响。组件之间互相调用，会变成“你改我、我改他”的耦合地狱。

第一反应：组件彼此直接引用

brandSelect.onChange(() => priceSlider.setRange([0, 500]));
priceSlider.onChange(() => tagPanel.disable("promo"));

灾难：联动规则散落，改一处崩一片

双向依赖：A 调 B，B 又调 A。
逻辑难维护：联动规则散落在各个组件里。

解决思路：用中介者统一协调

type MediatorEvent =
  | { type: "brand:change"; value: string }
  | { type: "price:change"; value: [number, number] }
  | { type: "reset" };

class FilterMediator {
  // 中介者统一协调组件
  private components = new Set<{ reset: () => void }>();

  register(component: { reset: () => void }) {
    this.components.add(component);
  }

  notify(sender: unknown, event: MediatorEvent) {
    // 根据事件协调组件行为
    if (event.type === "reset") {
      this.components.forEach((c) => c.reset());
      return;
    }
    if (event.type === "brand:change") {
      // 规则集中在中介者
      if (event.value === "官方自营") priceSlider.setRange([0, 300]);
    }
  }
}

const mediator = new FilterMediator();

const brandSelect = {
  reset: () => setBrand(""),
  // 变化只通知中介者
  change: (value: string) => mediator.notify(brandSelect, { type: "brand:change", value }),
};

const priceSlider = {
  reset: () => setPrice([0, 999]),
  // 暴露被中介者调用的 API
  setRange: (range: [number, number]) => setPrice(range),
};

mediator.register(brandSelect);
mediator.register(priceSlider);

中介者把“组件之间的对话”集中到一个地方，耦合大幅降低。

访问者模式（Visitor Pattern）

前端真实场景：组件树的“统计/导出/渲染”多种操作

设计器里的节点既要渲染，也要导出 JSON，还要统计图片数量。如果把逻辑都塞进节点类，节点会爆炸。

第一反应：在每个节点里塞一堆方法

class Node {
  render() {}
  exportJson() {}
  countImages() {}
}

灾难：节点越来越臃肿

新增行为必须改所有节点。
逻辑难复用：统计/导出/渲染互相污染。

解决思路：访问者把“行为”独立出来

interface Element {
  // 接受访问者
  accept(visitor: Visitor): void;
}

class TextElement implements Element {
  constructor(public text: string) {}
  accept(visitor: Visitor) {
    // 双分派：把自己交给访问者
    visitor.visitText(this);
  }
}

class ImageElement implements Element {
  constructor(public src: string) {}
  accept(visitor: Visitor) {
    visitor.visitImage(this);
  }
}

interface Visitor {
  // 不同节点的访问入口
  visitText(el: TextElement): void;
  visitImage(el: ImageElement): void;
}

class ExportVisitor implements Visitor {
  // 导出结果
  public output: any[] = [];
  visitText(el: TextElement) {
    // 文本节点导出
    this.output.push({ type: "text", value: el.text });
  }
  visitImage(el: ImageElement) {
    // 图片节点导出
    this.output.push({ type: "image", src: el.src });
  }
}

const elements: Element[] = [new TextElement("Hello"), new ImageElement("/logo.png")];
const visitor = new ExportVisitor();
// 遍历节点，交给访问者处理
elements.forEach((el) => el.accept(visitor));

访问者让“行为”可插拔，节点本体保持干净。

解释器模式（Interpreter Pattern）

前端真实场景：可配置的筛选表达式

筛选表达式从“勾选条件”升级到“输入语法”，比如 tag:react AND (type:post OR type:note)。

第一反应：在一个函数里手写解析

if (query.includes("AND") && query.includes("OR")) {
  // 很快变成一坨 if/else
}

灾难：规则复杂，维护成本指数级

扩展困难：新增 NOT、括号就要重写。
难以测试：解析逻辑与业务逻辑纠缠。

解决思路：把表达式建成语法树

type Context = { tag: string; type: string };

interface Expression {
  // 解释表达式
  interpret(ctx: Context): boolean;
}

class TagExpression implements Expression {
  constructor(private value: string) {}
  interpret(ctx: Context) {
    // 终结符表达式：判断 tag
    return ctx.tag === this.value;
  }
}

class TypeExpression implements Expression {
  constructor(private value: string) {}
  interpret(ctx: Context) {
    // 终结符表达式：判断 type
    return ctx.type === this.value;
  }
}

class AndExpression implements Expression {
  constructor(private left: Expression, private right: Expression) {}
  interpret(ctx: Context) {
    // 组合表达式
    return this.left.interpret(ctx) && this.right.interpret(ctx);
  }
}

class OrExpression implements Expression {
  constructor(private left: Expression, private right: Expression) {}
  interpret(ctx: Context) {
    return this.left.interpret(ctx) || this.right.interpret(ctx);
  }
}

function evaluate(ctx: Context, expression: Expression) {
  // 统一入口
  return expression.interpret(ctx);
}

const expr = new AndExpression(
  new TagExpression("react"),
  new OrExpression(new TypeExpression("post"), new TypeExpression("note")),
);

evaluate({ tag: "react", type: "note" }, expr);

解释器把“语法”变成对象，规则扩展也就有路可走。

总结：行为型模式到底在帮你什么？

行为型模式解决的是“协作与流程问题”。它让系统更像一个可编排的流程，而不是一堆互相牵扯的 if/else。

模式	重点	解决什么耦合
发布订阅模式	事件解耦	组件之间的直接依赖
策略模式	规则替换	条件分支与核心流程的绑定
状态模式	状态驱动	多状态布尔组合的混乱
责任链模式	流程分段	规则组合与顺序调整的困难
命令模式	操作对象化	不可撤销的操作与历史记录缺失
模板方法模式	固定流程骨架	重复流程带来的维护成本
迭代器模式	统一遍历协议	复杂结构遍历逻辑散落各处
备忘录模式	状态快照	撤销/恢复与业务状态的强耦合
中介者模式	协调通信	组件互相直接引用
访问者模式	行为外置	行为扩展导致的节点类膨胀
解释器模式	规则语法化	解析规则与业务逻辑的强耦合

最后用一句前端味更重的话收尾

当你的业务开始“指挥谁先干、谁后干、谁失败要重试”，行为型模式就在提醒你：把流程调度交出去，业务就会更轻。

设计模式：结构型模式

Sun, 31 May 2026 11:41:42 GMT

结构型模式到底在解决什么？

结构型模式的核心，只有一个问题：如何组合类或对象。它的出发点不是“再发明一个轮子”，而是在不破坏原有结构的前提下，通过继承或组合去扩展新功能，让原来的结构变得更强大。

它通常在以下这些场景出现：接口不兼容但又不能全盘重写；系统需要动态扩展功能但不想动核心；以及在“更细粒度、更高效率”之间做权衡时，想要一条更稳的路。

一句话总结

“怎么连接/拼装”这件事，和“怎么使用”分开。

适配器模式（Adapter Pattern）

前端真实场景：后端统一调整了响应体结构

Axios 是前端的“空气”，但空气也会突然被后端改配方。比如原来后端约定的响应体是 { code, data, msg }，现在一换版本，变成了 { status, payload, message }。

第一反应：全项目一处处改字段

const res = await axios.get("/api/user");

if (res.data.status === 0) {
  userStore.set(res.data.payload);
}

灾难：改不完、改不稳、改了还会漏

调用点满地开花：你要改的不是一个接口，而是 200 个页面。
历史模块崩盘：老代码依旧在拿 code 和 data，很容易出现“业务没报错但数据全空”的隐性灾难。

解决思路：给 axios 装一个适配器

type LegacyResult<T> = { code: number; data: T; msg: string };
type NewResult<T> = { status: number; payload: T; message: string };

function adaptResponse<T>(raw: NewResult<T>): LegacyResult<T> {
  return {
    code: raw.status,
    data: raw.payload,
    msg: raw.message,
  };
}

const http = axios.create();

http.interceptors.response.use((res) => {
  return {
    ...res,
    // 统一回旧协议，业务层无需改动
    data: adaptResponse(res.data),
  };
});

type User = { id: string; name: string };

async function getUser(id: string) {
  const res = await http.get<LegacyResult<User>>(`/api/user/${id}`);
  if (res.data.code !== 0) throw new Error(res.data.msg);
  return res.data.data;
}

业务层继续写老协议，变更只集中在适配器里，后端怎么换，你只改一个文件。

装饰器模式（Decorator Pattern）

前端真实场景：统计每个请求的耗时与性能

我们经常要统计接口耗时、加上错误上报，或者做统一的 loading。装饰器的核心就是：不改原函数，只给它套一个“外壳”。

第一反应：在函数内部直接加逻辑

async function fetchUser(id: string) {
  const start = performance.now();
  const res = await http.get(`/api/user/${id}`);
  const cost = performance.now() - start;
  reportPerf("fetchUser", cost);
  return res.data;
}

灾难：横切逻辑污染业务函数

每个函数都要塞一遍：计时、上报、日志，全散在业务里。
改一个策略要全局改：性能埋点的规则变了，你要翻遍所有函数。

解决思路：装饰器把“横切关注点”抽离

function Timer(name?: string) {
  // 装饰器工厂：包一层计时逻辑
  return (_target: unknown, key: string, descriptor: PropertyDescriptor) => {
    const original = descriptor.value as (...args: any[]) => Promise<unknown>;
    descriptor.value = async function (...args: any[]) {
      const start = performance.now();
      try {
        return await original.apply(this, args);
      } finally {
        // 无论成功失败都上报耗时
        reportPerf(name ?? key, performance.now() - start);
      }
    };
    return descriptor;
  };
}

class UserService {
  @Timer("fetchUser")
  async fetchUser(id: string) {
    const res = await http.get(`/api/user/${id}`);
    return res.data;
  }
}

直接用 TypeScript 装饰器语法，业务函数不用改，横切逻辑集中在装饰器里。

代理模式（Proxy Pattern）

前端真实场景：响应式状态与自动更新

Vue 3 能做到“改数据 -> UI 自动更新”，核心并不是“自动变魔术”，而是 Proxy 拦截 get/set，在 get 时收集依赖，在 set 时触发更新。这就是“响应式系统”的本体。

第一反应：手动维护状态和通知

const state = { count: 0 };
const listeners: Array<() => void> = [];

function setCount(n: number) {
  state.count = n;
  listeners.forEach((fn) => fn());
}

灾难：你在手工写一个残次版响应式系统

可维护性极差：每个字段都要写 setter。
一致性失控：有人直接改 state.count，监听就断了。

解决思路：手写一个最小可用的响应式

type EffectFn = () => void;

// target -> key -> effects
const bucket = new WeakMap<object, Map<PropertyKey, Set<EffectFn>>>();
// 当前正在执行的副作用
let activeEffect: EffectFn | null = null;

function effect(fn: EffectFn) {
  // 注册副作用：执行时会触发依赖收集
  const runner = () => {
    activeEffect = runner;
    fn();
    activeEffect = null;
  };
  runner();
}

function track(target: object, key: PropertyKey) {
  // 依赖收集：记录“谁在用这个 key”
  if (!activeEffect) return;
  let depsMap = bucket.get(target);
  if (!depsMap) {
    depsMap = new Map();
    bucket.set(target, depsMap);
  }
  let deps = depsMap.get(key);
  if (!deps) {
    deps = new Set();
    depsMap.set(key, deps);
  }
  deps.add(activeEffect);
}

function trigger(target: object, key: PropertyKey) {
  // 触发更新：把依赖这个 key 的副作用全部重新执行
  bucket.get(target)?.get(key)?.forEach((fn) => fn());
}

function reactive<T extends object>(obj: T): T {
  return new Proxy(obj, {
    get(target, key, receiver) {
      const res = Reflect.get(target, key, receiver);
      // get 时收集依赖
      track(target, key);
      return res;
    },
    set(target, key, value, receiver) {
      const old = Reflect.get(target, key, receiver);
      const result = Reflect.set(target, key, value, receiver);
      // set 时触发更新
      if (old !== value) trigger(target, key);
      return result;
    },
  });
}

const state = reactive({ count: 0 });

effect(() => {
  const el = document.querySelector("#count");
  if (el) el.textContent = String(state.count);
});

state.count += 1;

业务不碰核心对象，只操作代理。依赖在 get 时收集、更新在 set 时触发，这就是 Vue3 响应式的关键脉络。

桥接模式（Bridge Pattern）

前端真实场景：同一套 UI 对接多种数据源

同一个图表组件既要展示“实时接口数据”，又要展示“本地 mock 数据”。如果把数据逻辑写死在组件里，UI 会被绑架。

第一反应：组件里写一堆 if/else

function renderChart(sourceType: "api" | "mock") {
  if (sourceType === "api") {
    // 拉接口 -> 转换 -> 渲染
  } else {
    // 读取本地数据 -> 渲染
  }
}

灾难：数据源越多，组件越像屎山

UI 组件承包所有业务：数据源、转换规则、渲染细节全混一起。
组合爆炸：数据源 _ 主题 _ 平台，组合数无限膨胀。

解决思路：桥接“UI 与数据源/渲染器”

type DataSource = () => Promise<number[]>;
type Renderer = (el: HTMLElement, series: number[]) => void;

const createApiSource = (): DataSource => async () => {
  const res = await http.get("/api/sales");
  return res.data;
};

const createMockSource = (): DataSource => async () => [120, 90, 150];

const renderBar: Renderer = (el, series) => {
  el.innerHTML = series.map((n) => `<div class="bar" style="height:${n}px"></div>`).join("");
};

const renderLine: Renderer = (el, series) => {
  el.innerHTML = `<svg>${series.map((n, i) => `<circle cx="${i * 40}" cy="${200 - n}" r="4"/>`).join("")}</svg>`;
};

async function mountChart(el: HTMLElement, source: DataSource, renderer: Renderer) {
  // 桥接：数据源与渲染器独立，组合时再拼接
  const series = await source();
  renderer(el, series);
}

// React/Vue 都可以这样用：数据源与渲染器自由组合
const el = document.querySelector("#chart") as HTMLElement;
mountChart(el, createApiSource(), renderBar);

UI 组件只关心“怎么画”，数据源只关心“从哪来”，组合靠桥接拼装，不会互相牵连。

组合模式（Composite Pattern）

前端真实场景：文件夹与文件的统一管理

文件系统里既有“文件夹”，也有“文件”。对 UI 来说都要渲染、都要统计大小、都要支持展开，但内部结构完全不同。

第一反应：写一堆判断

function renderNode(node: any) {
  if (node.children) {
    node.children.forEach(renderNode);
  } else {
    renderFile(node);
  }
}

灾难：你在手写“叶子/容器”分支地狱

每次调用都要判断类型：递归逻辑越来越复杂。
扩展节点类型困难：新增“分组”/“分割线”时全得改。

解决思路：统一成一种“节点”接口

type FileNode = {
  type: "file";
  name: string;
  size(): number;
  print(indent?: string): string[];
};

type FolderNode = {
  type: "folder";
  name: string;
  children: Node[];
  add(node: Node): void;
  size(): number;
  print(indent?: string): string[];
};

type Node = FileNode | FolderNode;

const createFile = (name: string, bytes: number): FileNode => ({
  type: "file",
  name,
  size: () => bytes,
  print: (indent = "") => [`${indent}- ${name} (${bytes}b)`],
});

const createFolder = (name: string, children: Node[] = []): FolderNode => ({
  type: "folder",
  name,
  children,
  add(node: Node) {
    children.push(node);
  },
  // 汇总子节点大小
  size: () => children.reduce((total, child) => total + child.size(), 0),
  print: (indent = "") => {
    // 递归打印树结构
    const lines = [`${indent}+ ${name}/`];
    children.forEach((child) => lines.push(...child.print(`${indent}  `)));
    return lines;
  },
});

const root = createFolder("src", [
  createFile("main.ts", 1200),
  createFolder("components", [createFile("Button.tsx", 800)]),
]);

root.add(createFolder("assets", [createFile("logo.png", 2048)]));
console.log(root.size());
console.log(root.print().join("\n"));

文件与文件夹都实现同一套节点接口，上层只管调用 size() / print()，不用知道它是单体还是组合。

外观模式（Facade Pattern）

前端真实场景：上传流程 = 压缩 + 鉴权 + 上传 + 通知

一个“上传头像”背后可能串了 4 个模块。如果每个页面都手动拼这些流程，维护将变成灾难。

第一反应：每个页面手写一套流程

await compress(file);
const token = await fetchUploadToken();
const url = await uploadFile(file, token);
await notifyProfile(url);

灾难：流程散落，错误处理碎一地

每个页面都得 copy 一遍：改个接口名要全局替换。
错误处理完全不一致：有的吞错，有的弹窗，有的啥也不做。

解决思路：外观模式统一入口

type UploadOptions = {
  onProgress?: (percent: number) => void;
  onError?: (err: unknown) => void;
};

async function uploadAvatar(file: File, options: UploadOptions = {}) {
  try {
    // 对外只暴露一个入口，内部步骤统一编排
    const compressed = await compress(file);
    const token = await fetchUploadToken();
    const url = await uploadFile(compressed, token, options.onProgress);
    await notifyProfile(url);
    return url;
  } catch (err) {
    options.onError?.(err);
    throw err;
  }
}

// UI 侧只关心一个入口
await uploadAvatar(file, {
  onProgress: (p) => setProgress(Math.round(p * 100)),
  onError: () => toast("上传失败"),
});

对外只有一个入口，复杂流程被“挡在门后”，这就是外观模式的价值。

享元模式（Flyweight Pattern）

前端真实场景：地图上成千上万的标记点

地图上有 1 万个点，它们的样式都一样，只有坐标不同。你如果每个点都 new 一份图标对象，内存直接顶满。

第一反应：每个点都独立创建图标

const markers = points.map((p) => new Marker(p, new Icon("shop")));

灾难：内存暴涨 + 初始化卡顿

对象重复创建：1 万个 icon 明明长一样，却重复造了 1 万次。
渲染启动时卡顿：初始化全在主线程上堆着。

解决思路：共享“内在状态”，外部传“外在状态”

class IconFactory {
  private cache = new Map<string, Icon>();

  get(type: string) {
    // 相同类型复用同一个 Icon
    if (!this.cache.has(type)) {
      this.cache.set(type, new Icon(type));
    }
    return this.cache.get(type)!;
  }
}

const iconFactory = new IconFactory();

const markers = points.map((p) => ({
  position: p, // 外在状态
  icon: iconFactory.get("shop"), // 内在状态共享
}));

function renderMarker(marker: { position: { x: number; y: number }; icon: Icon }) {
  drawIcon(marker.icon, marker.position);
}

只要图标类型不变，Icon 永远复用，内存压力瞬间降一个数量级。

总结：结构型模式到底在帮你什么？

结构型模式关心的不是“对象怎么来”，而是对象怎么被拼接与复用。它让结构能长大，但不会把原有系统撕碎。

模式	重点	解决什么耦合
适配器模式	兼容新旧接口	接口变化导致的全量改动
装饰器模式	横切能力叠加	业务逻辑与统计/监控/日志的混杂
代理模式	间接访问控制	直接操作对象导致的状态失控与无拦截点
桥接模式	抽象与实现分离	UI 与数据源/主题的组合爆炸
组合模式	树形一致访问	叶子与容器的分支判断地狱
外观模式	统一入口	多模块流程散落、错误处理不一致
享元模式	共享内在状态	重复对象带来的内存与性能浪费

最后用一句前端味更重的话收尾

当你发现一个组件需要知道“内部结构到底拼了多少层、谁要先执行、谁要复用”，它已经开始失控了。

结构型模式要做的，就是把“拼结构的脏活”收回去，让业务层只管用、别管怎么连。

平平无奇打工人的一周

Sun, 17 May 2026 13:00:00 GMT

这一周，怎么说呢，平平无奇但又如鲠在喉。

标准的打工人一周，不仅在复杂的公司流程里反复横跳，还经历了一场猝不及防的裁员风波。唯一的慰藉大概是从面试中学到了一些东西，并对未来的跑路（划掉）职业规划有了更清晰的打算。

职场：被 AI 和流程“支配”的一周

智能 CR 的“死循环”

周一本来准备走上线流程，结果领教了所谓的“智能 CR”。只要你改了代码 push，就会触发 CR；根据 CR 的建议改完再 push，它又会重新触发 CR。感觉陷入了一个无尽的递归，真的难绷。到最后，能拒绝的我都让 AI 帮我写理由拒绝了。 让 AI 给我一个理由，去拒绝另一个 AI，这很 Cyberpunk。

上线流程的“九九八十一难”

因为我的需求涉及到四个仓库的变更，那个上线流程简直麻烦到想哭：

先要找到部署主干道。
因为是 Release 到发布模型，会自动创建一个 Release 分支。
上线时要锁死分支。
找测试要“准入准出”报告。
提交上线单并等待 Main 测试。
完成 +1 审批。
如果是白名单需求，还要在线上环境下进行回测。

最绝的是，第一次准备上时，产品突然要加个字段。后端说因为比较固定，让我前端直接写死。这一写死，我就得重新改三个仓库，撤销上线单，重新走 CR、MR、提交、找人审批…… 周四又因为正好撞上别人上线同一仓库，我又在修 Bug，只能让人家先上，我这边的流程又得重头再来。到了周五早上总算上完了，下午回测却发现后端逻辑有问题，需要后端修复。 结果： 原定周二上线的需求，周五依然卡在白名单里没上线成功。心态真的有点崩。

突如其来的离职风波

周一晚上被告知有同事要离职，让我去接手。起初以为是人家的主动选择，后来才知道是杭州那边裁了很多人。由于我们这边总共才 8 个人，结果也开了 2 个，还有一个转岗了。人少了，可需求一点没少，甚至还得去碰那个极其麻烦的“低代码”平台。

Token 危机

公司之前的 Token 限制是 2kw，现在改成了什么积分制。作为实习生，积分少得可怜，三天就能用完一个月的量。虽然能提额，但也只有三倍。感觉完全不够撑过一个月。

面试：成长的阵痛

这周参加了两场重量级面试，感受各异。

字节面试： 虽然觉得自己答得不错，但手撕代码能力还是太弱了。在 AI 时代，我总觉得这方面的占比应该可以弱化，但显然大厂还是非常看重硬实力。结果是惨遭“秒挂”，有点打击，但也认清了差距。
百度面试： 这场面试真的获益匪浅，甚至有点后悔没录音。面试官的深度真的离谱，我才知道百度原来藏着这么多大佬。我有一个朋友也在百度的那个组，感觉他们的人均水平都非常高。希望这次能走后续流程，如果能进去，哪怕只是跟着大佬学东西肯定也能飞速成长。

学习与计划

即使现在的工作干得心累（低代码业务跨度大、各平台逻辑不统一、开发效率低），但日子总要往前走。

夯实算法与总结

利用周末的时间总结了下简历对应的知识点，还有关于 AI 开发的一些心得。虽然 Token 受限，但思路不能断。接下来要开始死磕算法了，为秋招做准备。

拜读经典

这星期的 Reading List：

《设计模式》：希望能对现在的杂乱代码有点启发。
《人月神话》：去体会一下为什么“向进度落后的项目中增加人手只会使其进度更落后”。

碎碎念

其实好想跑路，但一想到 6.6 是快手十五周年，总想白嫖完活动再走（>_<）。但说认真的，目前的工作让我感到业务理解成本极高，但技术提升有限。确实希望能找个更好的去处，去学习更多真正的核心业务逻辑。

下周加油吧！

iframe 沙箱管控与 Schema 版本演进

Sat, 16 May 2026 12:25:00 GMT

模块一：iframe 跨域预览与微前端管控体系

在低代码或 CMS 系统中，iframe 是实现预览隔离的标准方案。但要做到“生产级”稳定，必须解决生命周期同步与安全隔离问题。

面试避坑：绝不能把 postMessage 比作 TCP。TCP 是底层的持久连接协议，而 postMessage 只是应用层的异步事件订阅/发布模型。

1. 双触发机制（解决生命周期竞态问题）

痛点：父页面直接发消息时，iframe 可能尚未挂载或初始化完成，导致消息丢失。
机制（状态机握手）：
- 触发 1（子找父）：iframe 内部组件 onMounted 后，主动发送。
- 触发 2（父找子）：父页面监听到 READY 信号后，再将配置数据通过 postMessage 安全下发。

2. 视口模拟（解决响应式失效陷阱）

误区：仅在外层 div 使用 transform: scale。这属于“视觉后渲染”，并未改变 iframe 内真实的 window.innerWidth，会导致 CSS 媒体查询（@media）和 vw/vh 单位失效。
正解（双层架构）：
- 内层（定死物理尺寸）：强行修改 iframe 的 width 和 height 为目标机型真实像素（如 375px），以激活移动端响应式代码。
- 外层（动态缩放）：监听可视区剩余空间，计算比例（如 0.75），用 transform: scale 将外层容器等比缩放。

3. 健壮性与安全防御

沙箱隔离（Sandbox）：使用 sandbox="allow-scripts allow-same-origin"。这是浏览器级的硬隔离，防范第三方模板恶意劫持顶层页面（修改 window.parent.location）或弹出干扰 UI。
超时保护：父页面加载时开启定时器。若 5 秒内未收到 READY 信号，立刻销毁 iframe 并展示兜底 Error UI，避免用户死等。

4. 父子应用状态哲学

单向数据流：父应用（控制台）是“大脑”，掌控 Schema 数据流转；子应用（iframe）是“哑巴组件”，不保存业务状态，只负责接收 JSON 并渲染视图。

模块二：Schema 驱动配置与版本演进体系

Schema 驱动的核心思想是“数据即视图”，用 JSON 替代硬编码，实现组件的动态插拔。

1. 配置闭环全链路

定义：用 JSON 描述组件结构（字段、类型、校验规则）。
配置：引擎解析 Schema，自动生成可视化输入面板。
渲染：真实数据存入数据库，预览端（iframe）拿到数据后动态反解并挂载组件。

2. 版本升级难题（面试杀手锏）

痛点：当组件库升级（如 V1 只需要 color，V2 改成了 style.color），数据库里存的几千条历史数据会因结构不符导致渲染崩溃。
破局解法（版本戳 + 适配器模式）：
- 打版本戳：所有存入数据库的 Schema 必须带有显式的版本号声明（如 __version: "1.0.0"）。
- 数据清洗层（Migration Pipeline）：在引擎渲染前加入拦截器。若发现是旧版数据，通过预写的适配函数（Adapter），自动将其 Map（转换）成最新结构。
- 收益：保证了底层渲染引擎的纯粹性，永远只按最新结构开发。历史包袱全部由清洗层“消化”。

破解水合错误（Hydration Mismatch）与性能调优

Sat, 16 May 2026 12:15:00 GMT

1. 为什么会触发水合错误？（底层细节）

核心本质： SSR 的流程是两步走的。第一步：服务端（Node.js）把 Vue/React 组件渲染成纯 HTML 字符串发给浏览器（此时页面能看，但点不动）。第二步：浏览器下载完 JS 后，框架会在客户端再把组件“虚拟渲染”一遍（生成 VDOM），并试图把它和刚才接收到的 HTML 结构“严丝合缝”地对齐，然后把点击、滚动等事件绑定上去。这个对齐并绑定的过程就叫水合（Hydration）。

只要客户端在初始化时计算出的 VDOM，和它看到的真实 DOM（服务端给的 HTML）有任何一丁点不一样，框架就会抛出 Hydration Mismatch 报错。

四大高频触发场景：

时空差异（宿主环境不同）：模板里写了 <div>{{ window.innerWidth }}</div>。服务端 Node.js 没有 window 对象，直接渲染成空值；而客户端渲染出真实的宽度。
状态非同构（数据不一致）：服务端请求了接口拿到了数据 A 渲染了页面，但没有把数据 A 传给客户端。客户端一接手，发现本地没有数据 A，渲染成了空状态。
非确定性输出：模板里使用了 Math.random() 或 new Date()。服务端生成了一个时间戳，客户端接管时又生成了一个新的。
非法的 HTML 结构：比如 <p><div></div></p>。浏览器在解析这段服务端 HTML 时会自动纠错（把 div 挪到 p 外面）。等由于水合时发现 DOM 结构变了，导致对不上。

2. 怎么解决水合错误？（工程实战拆解）

在构建高性能 Web 应用时，为了保证首屏极速加载，必须重度依赖 SSR，这就要求我们在架构设计上主动规避水合问题。

解法一：同构数据预取 (Isomorphic Data Fetching)

解决的问题：“状态非同构”导致的不匹配。
原则：代码在服务端和客户端都能跑。
链路：服务端请求数据并渲染 HTML，同时将数据序列化并注入到 HTML 底部的 <script id="__DATA__"> 标签里。客户端接手后，直接从该标签里“脱水（Dehydrate）”出数据，确保两端数据源绝对一致。

解法二：按需挂载 (Client-Only / On-Demand Mounting)

解决的问题：“宿主环境不同”或“非确定性输出”导致的不匹配。
链路：对于强依赖浏览器 API（如 CSS 3D 参数、IntersectionObserver）的组件，使用 <ClientOnly> 包裹，或者在 onMounted 钩子中执行渲染。服务端渲染时仅显示骨架屏，客户端水合完成后再挂载真实组件。

3. 开发 / Prod 环境遇到报错的应对策略

开发环境 (Dev)：
- 现象：控制台打印明确的红色警告（Hydration node mismatch…），指出具体的期望节点与实际节点。
- 排查：定位组件，检查是否误用了 window/document 或数据状态前后端不一致。
生产环境 (Prod)：
- 现象：为了性能，Vue/React 会移除警告。如果发生不匹配，它会默默执行“放弃水合（Bailout）”，销毁服务端 DOM 并重新渲染。
- 后果：出现页面闪烁（FOUC），SSR 优势丧失，转换为普通的 SPA。
- 监控：通常需借助 Sentry 捕获异常，或利用 Lighthouse 分析 TTI 是否异常偏高。

4. 架构师进阶：SSR 核心补充知识点

A. 内存泄漏与状态污染（State Pollution）

风险：在 SSR 中，所有请求共享同一个 Node.js 进程。如果使用全局变量或未在请求结束时销毁状态实例，用户 A 的数据可能会“泄露”给用户 B。
原则：必须保证每一次请求，所有的状态中心（如 Pinia/Redux）都是全新实例化的。

B. 核心性能指标

TTFB (Time to First Byte)：服务端响应速度。SSR 计算越复杂，TTFB 越高。
FCP (First Contentful Paint)：内容首次绘制。SSR 极大提升了该指标，让用户更快“看到”页面。
TTI (Time to Interactive)：可交互时间。这就是水合完成的时间点。如果 JS 包过大或水合报错，TTI 会被严重拖慢。

C. Serverless 冷启动 (Cold Start)

SSR 应用部署在云函数时，冷启动（加载环境及解析代码）会带来数百毫秒延迟。
策略：配合骨架屏与边缘计算，或者在冷启动期间提供自动兜底链路，保护前端用户体验。

从渲染管线到 3D 动画性能优化

Sat, 16 May 2026 12:05:00 GMT

1. 核心底层八股：浏览器的渲染管线 (Render Pipeline)

这是所有性能优化的基石，面试官如果深挖，一定会问：为什么 transform 做动画就不卡？

标准渲染流程：JavaScript -> Style（计算样式） -> Layout（重排/回流） -> Paint（重绘） -> Composite（合成）。
卡顿的元凶：如果你用 width、top、margin 来做翻书动画，每一帧都会触发 Layout 和 Paint，这些都在 CPU 的主线程运行，非常昂贵，必然掉帧。
硬件加速的原理：当你使用 transform 或 opacity 做动画时，浏览器极其聪明，它会直接跳过 Layout 和 Paint，直接进入 Composite 阶段。并且，它会将这个元素提取到一个独立的图层 (Compositing Layer)，交由 GPU 去专门处理。GPU 天生就是做矩阵变换和图层叠加的，所以动画会如丝般顺滑。

2. 实战考点：怎么调用/触发 GPU 硬件加速？

面试官会问：除了写 transform，还有什么方法强制开启硬件加速？

经典 Hack 写法 (Translate3D)：transform: translateZ(0) 或 transform: translate3d(0, 0, 0)。虽然位移是 0，但这是在欺骗浏览器：“嘿，这是一个 3D 元素，赶紧把它单独放到 GPU 图层里去！”
现代优雅写法 (Will-Change)：will-change: transform;。这是明确告诉浏览器：“这个元素的 transform 属性马上要变了，请提前做好 GPU 资源分配和图层提升准备。”
还有哪些情况会自动触发：<video> 标签、<canvas>、CSS Filter 等。

3. 样式考点：实现立体书必须要懂的 3D 属性

仅仅靠位移是不够的，实现立体翻书效果，你的 CSS 里必须要出现这三个核心属性：

perspective: 800px; (透视/景深)：
- 没有透视，翻书看起来就像是一个面在不断变窄；加了透视，才有“近大远小”的 3D 纵深感。数值越小，透视感越畸形（贴脸看）；数值越大，越平缓。
transform-style: preserve-3d; (保留 3D 空间)：
- 必须加在书本的父容器上！如果不加，当你翻开封面时，封面会被拍扁在父容器的 2D 平面上。加了它，子元素才能真正脱离平面，在 Z 轴上穿插。
backface-visibility: hidden; (背面不可见)：
- 超级重要的优化点！当书页翻过去 180 度时，背面其实是不应该被看到的。加上这个属性，GPU 就不需要去计算和绘制翻过去之后的背面像素，极大节省了渲染开销。

4. 架构考点：JS 怎么配合优化 3D 动画？

虽然渲染交给了 GPU，但“翻书的角度（进度）”往往是由用户手指滑动触发的，这就需要 JS 出马了。面试官会问：滑动翻书时，JS 怎么写最流畅？

使用 requestAnimationFrame (rAF)：
- 绝不要用 setTimeout 或 setInterval 去更新 rotateY 的角度。rAF 会让你的 JS 执行频率与浏览器的屏幕刷新率（通常是 60fps）绝对同步，避免掉帧。
事件节流 (Throttling) 与被动监听 (Passive Events)：
- 用户的 touchmove 事件触发频率极高。在绑定监听器时加上，告诉浏览器“我不会调用 preventDefault() 阻止默认滚动”，这样浏览器主线程就不会等待你的 JS 执行，滑动会立刻响应。
分离读写操作 (避免 Layout Thrashing)：
- 如果你在滑动时，先读取一下 element.clientWidth，紧接着立刻修改 element.style.transform，这会强制浏览器提前进行重排（强制同步布局）。必须把所有的“读”操作集中在一起，所有的“写”操作集中在一起放到 rAF 里执行。

5. 终极避坑（面试加分项）：图层爆炸 (Layer Explosion)

如果你回答得太好，面试官会抛出最后的杀手锏：硬件加速有什么副作用吗？能滥用吗？

副作用：每一个独立的 GPU 合成层都会消耗额外的内存。如果给页面上所有的元素都加上 will-change: transform，会导致图层爆炸。手机内存吃紧，反而会让整个页面卡死甚至闪退。
Z-index 陷阱：如果一个 z-index 较低的元素被提升到了 GPU 独立图层，为了保证层叠顺序的正确性，浏览器会被迫把覆盖在它上面的所有 z-index 较高的普通元素也提升为独立图层（隐式合成）。这也是导致图层爆炸的常见原因。
如何治理：动画开始前加上 will-change，动画结束后立刻通过 JS 将其移除（element.style.willChange = 'auto'），把图层交还给浏览器释放内存。

如何更好使用 AI（从上下文治理到 MCP 协议）

Sat, 16 May 2026 06:00:00 GMT

模块一：上下文治理 —— 解决 AI 的“失忆与注意力涣散”

大模型的底层逻辑是无状态特性的（Stateless），每次对话都会把历史记录打包成一个巨大的 JSON 数组全量发送。上下文越长，API 越贵，且 AI 越容易产生幻觉（忘记初始设定）。

为了保持 AI 的“绝对清醒”，工程上衍生出了以下四大治理手段：

1. Sub-agent 模式（物理隔离）

痛点：遇到具体的细节 Bug 时，如果直接在主会话中让 AI 反复试错，这些“垃圾过程”会严重污染上下文，导致主 Agent 忘记全局架构设计。
解法：主 Agent 充当架构师（保持上下文纯净）；遇到 Bug，临时拉起一个 Sub-agent（修 Bug 专员）独立试错，成功后只把最终代码返回给主会话。
经典使用场景：你在开发 C 端阅读平台时，主 Agent 帮你搭好了 Nuxt 4 的整体架构。但在写立体书翻页效果时，CSS 3D 动画一直有透视错错乱的 Bug。此时千万别在主对话里来回贴报错代码，而是把这个独立的翻页组件单独发给一个 Sub-agent 去疯狂调优，调顺滑了，再把最终的组件代码合并回主干。

2. 对话分支与状态回溯 (Conversation Forking / Backtracking)

痛点：在解决复杂问题时，AI 经常会给出错误的技术路线（比如引入了一个不兼容的库）。顺着这个路线聊下去，会引发更多连锁报错，导致整个对话陷入“疯狂补锅”的死胡同。
解法：像 Git 回滚一样，在对话历史中找到“走偏前的那一条消息”，直接执行回溯（或者 Fork 出一个新分支）。此时不仅代码状态回到了过去，大模型的“脑子”（上下文记录）也被清除了那段失败的试错记忆。
经典使用场景：你遇到一个 SSR 水合报错 (Hydration Mismatch)。AI 建议你安装一个第三方 NPM 插件来解决，结果安完之后报了 10 个跨域相关的错，你们顺着这 10 个错又排查了 5 轮，越弄越乱。此时直接回退到 AI 提议装插件前的那句话，放弃这条错误路线，让 AI：“这个插件会引发更多问题，请提供一个纯原生的同构预取方案。”

3. /compact 摘要机制（状态压缩）

痛点：历史对话过长面临 Token 溢出（滑动窗口直接截断会丢失早期设定的关键规范）。
解法：利用大模型做“记忆快照”。将几十轮废话压缩成高密度的结构化文本，替换掉冗长的原始历史，既省 Token 又防偏题。
经典使用场景：项目开发了一周，当前的对话历史里堆满了你们关于数据库选型、早期表单交互方案的争论。现在你准备开始写核心逻辑了，直接使用 /compact，大模型会在后台把前面的长篇大论压缩成：“【当前状态】前端使用 Vue 3；【核心约定】严格校验类型，不可变数据更新；【下一步】开发文章渲染模块”。让 AI 甩掉历史包袱，轻装上阵。

4. 代码检索的演进（RAG 的局限与 AST 突围）

痛点：传统的向量检索（RAG）靠“语义相似度”找代码极不靠谱，经常把带有相同单词的无关注释找出来，却漏掉了真正互相依赖的函数。
解法：利用 AST（抽象语法树）与符号表检索（Symbol Search）进行精确的上下文提取，让 AI 像真正的编译器一样顺藤摸瓜找依赖。
经典使用场景：你在开发一个智能体平台，想让 AI 帮你修改 User 相关的状态逻辑。传统的 RAG 可能会找出所有写着 “user” 这个词的无用文件；而通过 ts-morph 等 AST 工具进行静态分析，系统能精确提取出你定义的 TypeScript 接口类型（Interface）、与之关联的全局状态树（Store）以及调用的 API 函数，将最精准的上下文喂给 AI，彻底消灭代码幻觉。

模块二：工具链范式演进（Toolchain Evolution）—— 如何让 AI 具备行动力

目前的研发效能工具链正在经历从“喂饭式”到“自主式”的演进，核心分为两大流派：

Skill + Bash（敏捷范式）：
- 本质：Prompt as Code。把高频开发场景沉淀为结构化的“技能卡片”。
- 运作：不再给 AI 封装繁琐的读写函数，而是直接给它赋予 Bash（终端）权限。AI 像真实程序员一样，遇到问题自己敲 cat 读文件、grep 搜代码。效率极高，是目前 Cursor / Devin 等先进工具的主流玩法。
MCP 协议（重型防御）：
- 本质：Model Context Protocol，强类型、强定义的 API 边界。
- 运作：人类必须手写具体的工具函数（如 query_db），并定义严格的入参 Schema。AI 只能在规定好的函数列表中选择调用，无法越界。

模块三：MCP 深度祛魅 —— 穿透黑盒看底层原理

虽然外界把 MCP 传得很神，但作为架构师，必须看透它的物理形态和生态定位。

1. 祛魅：它只是一个 Node.js 进程

MCP Server 听起来高大上，剥开来看，它就是一个常驻在后台的普通 Node.js / Python 脚本。它没有任何黑魔法，只是执行着普通的本地文件读写（fs.readFile）或数据库查询逻辑。

2. 底层原理与作用（AI 界的 USB 接口）

原理：它是基于 JSON-RPC 2.0 规范设计的 C/S 架构。大模型客户端（如 Roo Code）通过标准输入输出（stdio）或 HTTP (SSE)，向你的 Node 进程发送规定格式的 JSON 字符串指令；Node 进程处理完后，再以 JSON 格式将结果打印返回。
作用：统一规范。以前给不同的 AI 写插件要适配不同接口，现在只要按 MCP 规范写一次本地服务，任何支持 MCP 的大模型“插上就能用”，极大降低了给 AI 写“外挂”成本。

3. 如何实现一个 MCP 服务器

通常不需要从零手写解析逻辑。在 Node.js 环境下，会直接引入官方的 @modelcontextprotocol/sdk（或 FastMCP 等轻量框架）。实例化 Server 后，调用 SDK 暴露的 API 去注册 Tool（定义函数名、入参 Schema 和执行逻辑），最后启动服务监听 stdio 即可。

模块四：安全边界与容错率 —— 为什么生产环境必须用 MCP？

既然 Bash 模式开发效率这么高，为什么在敏感场景或生产环境依然要用看似繁琐的 MCP？这取决于爆炸半径与容错率的差异：

本地开发环境（适合 Bash，极致提效）：
- 容错率极高：有 Git 作为“后悔药”（git reset --hard 瞬间恢复）。
- 人在回路（Human-in-the-loop）：危险操作前会有确认弹窗，人类的双眼是最后一道防线。
- 爆炸半径小：哪怕 AI 产生幻觉执行了 rm -rf /，损失的也只是一台个人电脑的环境。
线上生产环境（必须 MCP，极致安全）：
- 数据不可逆：真实的业务数据库被删改是灾难性的，无法简单撤销。
- 无人值守：Agent 通常在后台异步运行，一旦产生幻觉（大模型的概率性缺陷），没有任何人能拦住它。
- 爆炸半径极大：涉及全量用户资产 and 公司生命线。
- MCP 的核心价值：用人类编写的、确定性的沙盒代码（权限校验、只读拦截），去兜底大模型概率性的危险行为。它是关住猛兽的那道防弹玻璃。

字节跳动_中国交易与广告(上海)面经

Tue, 12 May 2026 11:00:00 GMT

字节跳动_中国交易与广告(上海)

面试时间

2026_0512-19:00

面试内容

自我介绍
DataAgent 的项目是怎么样的？能介绍一下吗？
大概说一下这个项目的前端内容有哪些呢？
这个项目中你主要负责什么？
AI 返回的 ECharts 图表有考虑过万一 AI 报错了怎么办呢？
第二个项目中，你有遇到什么难题，挑几个说一下吧。
看你之前写了一个 MCP 服务器，能详细解释一下这个吗？
Agent 相关的了解吗？可以讲一下吗？
你对 Skill 的理解是什么？
能讲一下你怎么理解 RAG 吗？
你提到最新的框架都有 llms.txt，面试官和我讲了一下 IDE 里面 RAG 和搜索的两种方式。
JS 基本数据类型
开发中引用类型和基本数据类型有什么要注意的点吗？
Vue 和 React 都了解吗？
可变数据和不可变数据有了解吗？
React 中更改数据需要返回的 set 方法去更改，那引用类型有什么需要注意的吗？
代码性能问题分析：

function parseLines(files) {
  return String(files).split("\n");
}

function renderLinesSlow(files, container) {
  const text = parseLines(files); // 几十万行的文本
  for (const line of text) {
    const dom = document.createElement("p");
    dom.textContent = line;
    container.append(dom);
  }
}

问题：频繁 append + 一次性渲染过多节点，主线程阻塞、页面卡顿。
优化：虚拟滚动、分片渲染（requestIdleCallback / setTimeout）、DocumentFragment 批量插入。

手撕代码：异步并发调度器（实现一个 Scheduler 类，控制异步任务并发数量）

class Scheduler {
  constructor(limit) {
    this.limit = limit; // 最大并发数
    this.running = 0; // 当前运行中的任务数
    this.queue = []; // 等待队列
  }

  // 添加任务：接收一个返回 Promise 的函数
  add(task) {
    return new Promise((resolve, reject) => {
      this.queue.push({ task, resolve, reject });
      this._run();
    });
  }

  _run() {
    while (this.running < this.limit && this.queue.length) {
      const { task, resolve, reject } = this.queue.shift();
      this.running++;
      task()
        .then(resolve)
        .catch(reject)
        .finally(() => {
          this.running--;
          this._run();
        });
    }
  }
}

// 使用示例
const scheduler = new Scheduler(2);

const timeout = (ms, value) =>
  new Promise((resolve) => setTimeout(() => resolve(value), ms));

scheduler.add(() => timeout(1000, "A")).then(console.log);
scheduler.add(() => timeout(500, "B")).then(console.log);
scheduler.add(() => timeout(300, "C")).then(console.log);
scheduler.add(() => timeout(400, "D")).then(console.log);

// 输出顺序：B, C, A, D （并发数为2，按完成时间输出）

面试复盘总结

1) AI 图表报错题：前端需要给出“安全 + 稳定 + 体验”三层答案

面试官在考什么

不是只问“报错了怎么重试”，而是考你是否理解：AI 生成内容默认不可信，前端必须做执行隔离和防御式渲染。

完整回答模板

安全隔离（第一优先级）
- 不直接在主文档执行 AI 生成代码。
- 通过 iframe sandbox 隔离执行环境，最小权限原则。
- 配合 CSP、白名单资源域名，避免任意脚本执行和数据外泄。
运行时可观测（第二优先级）
- 在 iframe 内注入错误监听：window.onerror、unhandledrejection。
- 通过 postMessage 上报错误类型、堆栈、数据片段、traceId。
- 父页面统一状态机：生成中 -> 成功 -> 失败 -> 重试中 -> 兜底。
输入约束（第三优先级）
- 不让 AI 输出可执行 HTML/JS。
- 让 AI 输出 ECharts option JSON。
- 前端做 Schema 校验 + 字段白名单（禁危险 formatter / function 注入）。
- 校验通过后再安全实例化图表。
UX 降级
- 重试期间展示骨架屏和进度状态。
- 最终失败提供“重试 / 查看错误摘要 / 切换表格视图”。
- 保证页面不白屏、不阻塞核心流程。

一句话总结

AI 能提升上限，但前端必须负责下限：不崩、不炸、不泄露、可恢复。

2) SSR 水合不匹配：从“渲染时机”理解本质

本质

SSR 先在服务端生成 HTML。
客户端再执行一次首渲染并绑定事件（Hydration）。
两边首帧结构或文本不一致就会 Hydration Mismatch。

高频触发点

首屏依赖浏览器对象：window、document、localStorage。
首屏包含不稳定值：Math.random()、Date.now()、时区差异格式化。
条件渲染分支在服务端与客户端条件不一致。

标准解法

浏览器依赖逻辑放 onMounted / useEffect。
首屏只渲染稳定占位，挂载后替换真实数据。
纯客户端模块用 ClientOnly 或动态导入关闭 SSR。
统一时区和格式化策略，避免日期字符串差异。

3) RAG、IDE 搜索、llms.txt：怎么讲得像工程实践

传统向量 RAG 的局限

语义相似度适合自然语言，不等于代码调用关系。
代码问题本质是“符号引用 + 依赖图”问题，误召回和漏召回更明显。

IDE 实际增强路径

结构化检索（AST / Symbol / LSP）
- 先用“定义/引用/调用链”精确找上下文。
- 再把命中片段喂给模型生成答案。
向量检索补充
- 适合注释、文档、历史方案、跨仓库经验。
长上下文模型
- 可一次喂入更大上下文（仓库文档、接口协议、llms.txt）。
- 优势是信息完整，风险是成本和噪声增加，需要分层裁剪。

面试表达建议

“我不会把 RAG 只理解为向量库，而是 结构化检索优先，向量检索补充，长上下文兜底 的混合策略。”

4) Vue vs React + 可变/不可变：把底层机制讲透

Vue 为什么可变也能更新

Vue3 基于 Proxy 拦截 get/set。
直接改 state.a = 2 时可追踪依赖并触发更新。

React 为什么强调不可变

React 依赖引用变化判断状态是否变化（浅比较语义）。
如果直接改原对象再 setState(原对象)，引用不变，可能 bailout 不重渲染。

标准写法

// 不推荐
obj.a = 2;
setObj(obj);

// 推荐
setObj({ ...obj, a: 2 });

可变 vs 不可变的工程取舍

不可变数据：可预测、易回溯、利于 memo 优化。
代价：拷贝成本与心智负担上升。
实战：关键状态保持不可变，重计算区域配合结构共享/局部优化。

5) JS 基础题串讲：数据类型 -> 内存 -> 拷贝 -> GC

第一步：破题——数据类型的分类

（面试官：JS 有哪些数据类型？）

答题话术：

“面试官您好，JS 的数据类型总体分为两大阵营：基本类型（Primitive）和引用类型（Reference）。基本类型包括 7 种：string、number、boolean、null、undefined、symbol、bigint。引用类型统称为 Object，里面包含了普通对象、数组（Array）和函数（Function）等。”

第二步：化解陷阱——String 装箱机制

（面试官追问：那 string 是基本类型吗？为什么它能调方法？）

答题话术：

“string 绝对是基本类型。但我们在开发中经常能写出 'hello'.length 这样的代码，这其实是 JS 引擎底层做了一个‘自动装箱’（Auto-boxing）的微操。

当我们试图访问基本类型的方法时，引擎会瞬间在内存里 new String('hello') 把它包装成一个临时对象，调用完 .length 后，这个临时对象就立刻被销毁了。所以我们感受不到它的存在，但这其实是引擎为了方便开发者而设计的语法糖。”

第三步：深挖底层——栈与堆的妥协

（面试官：基本类型和引用类型最本质的区别是什么？）

答题话术：

“它们最本质的区别在于内存分配策略。这其实是引擎为了兼顾运行速度和内存大小做出的妥协。

基本类型的大小是固定的，所以引擎把它们的值直接存在栈内存（Stack）中。栈的特点是按值访问，存取速度极快。

引用类型（比如一个巨大的 JSON 对象）大小不可控，如果全塞进栈里会严重拖慢上下文切换的速度。所以对象的实体被安置在广阔的堆内存（Heap）中。而栈里只存了一个‘指针’（内存地址），这个指针指向堆里的那个房间。

所以，当我们执行 let a = b 赋值时，基本类型是实打实地复制了一份值；而引用类型，仅仅是复制了那个指针。两者共享了堆里的同一个房间。”

第四步：闭环机制——引出垃圾回收（GC）

答题话术：

“正因为这种内存分离机制，才有了垃圾回收（GC）的区别对待。

栈内存的清理很简单，函数执行完、上下文一出栈，里面的基本类型和指针就跟着销毁了。

但堆内存里的对象不能随便删，引擎必须用标记清除算法（Mark-and-Sweep）。它会从全局根节点（Root）出发，顺着栈里的‘指针’去找。只要这根线还连着，说明对象‘可达’，就能活下来；如果栈里的指针被销毁了，堆里的那个对象就成了‘孤岛’，在下一次 GC 时就会被当成垃圾清掉。”

第五步：工程落地——开发中的避坑指南

（面试官：那这种区别，在实际开发中有什么需要特别注意的吗？）

答题话术：

“在实际工程开发中，理解了内存机制，主要有三个高频的注意点：

副作用与深浅拷贝的抉择：因为引用类型赋值只是复制指针，如果不小心修改了入参对象，会造成严重的全局数据污染（副作用）。所以在处理复杂状态时，我们需要有意识地使用浅拷贝（... 扩展运算符）或深拷贝（structuredClone）来做物理隔离。
框架的状态更新机制（不可变 vs 可变）：这点在 React 和 Vue 中体现得最明显。 React 崇尚‘不可变数据’（Immutable），它的 setState 底层是用 Object.is() 对比引用地址的。如果你直接 obj.a = 2 然后传进去，栈里的指针没变，React 会以为数据没更新导致页面卡死，必须传入一个全新拷贝的对象。而 Vue 是基于 Proxy 劫持的‘可变数据’，它能精确监听到对象内部字段的变化，所以允许我们直接修改原对象的属性。
防范内存泄漏：开发时如果不注意，闭包里引用了庞大的 DOM 节点，或者在全局 window 上挂载了对象、忘记清理定时器（setInterval），就会导致栈里的‘指针’一直存在，垃圾回收器（GC）就不敢去清空堆里的内存，久而久之页面就会卡顿甚至崩溃。”

五一周总结：旅行、换机与需求磨合期

Sun, 10 May 2026 12:00:00 GMT

本周小记

这个五一过得很开心，去了武汉和长沙。第一次非常具体地感受到“被照顾”的感觉，心里很暖。

也会忍不住想，如果以后能一直在一个城市，不用异地就更好了。现实是现在还在实习阶段，不实习就没有收入，不过没关系，先把眼前的路走稳，努力赚钱，后面会越来越好。

这周还终于抢到了北京国补，顺利换了手机。旧手机续航已经夸张到不到 3 小时，还伴随一堆 bug，体验真的很影响状态。换机之后，整个人的节奏都顺了不少。

工作进展

1) 从“摸索”到“进入需求”

前面一段时间总觉得自己有点“摸鱼”，但回头看，其实是在补基础：内部文档、平台流程、工具使用都在学。

这周开始正式推进需求，而且是个体量不小的需求：

排期大约 2 周开发 + 1 周测试
涉及 4 个微前端仓库改动
还牵扯一个老的 Vue2 项目

2) 老项目联调成本比预期高

老项目需要 Node 16 才能跑，而且存在已知问题：日志死循环会把磁盘写满。

这类历史包袱对开发节奏影响很大，也让我更直观地理解到“技术债”这件事不是抽象概念，而是每天都会付出的时间成本。

3) 低代码平台的实际痛点

这次在低代码平台上也踩了不少坑。最大的感受是：

网页端改动效率偏低
仓库里下发的 JSON 协议无法稳定手改
手动改完后，自动部署会重新下发协议把改动覆盖

很多时间花在“和平台对齐”而不是“写业务逻辑”上，体感比较挫败。

本周复盘

目前最大的问题不是“不会写代码”，而是对整体业务链路理解还不够深。

当业务全景没理清楚时，改动点会显得分散，做起来就容易反复。

下周计划

主动找 mentor 过一遍完整业务流程，补齐核心上下文。
用 AI 先做一版需求拆解：
- 业务目标是什么
- 涉及哪些系统/仓库
- 每个改动点的输入、输出、依赖关系是什么
在编码前先产出“改动点清单”，减少返工。

后台 CRUD 重构：三个页面合并成一个，维护效率翻倍

Fri, 24 Apr 2026 06:00:00 GMT

写在前面

这是我进公司后第一次独立负责一个完整需求——做一个业务单据的维护模块。

终于可以写点功能代码了！一顿操作：新建文件夹 → Create.vue、Edit.vue、Detail.vue，刚准备开始复制粘贴表单代码，mentor 过来 review 我的代码结构。

他看了看我的三个文件，问了一句：“这三个页面表单长得一样，为什么不写在一起，用路由参数切换状态？”

我愣了一下，好像… 还真是这么回事，之前也没有想过这些事情，因为三个路由就像是理所当然的，虽然他们好像确实差不多…？

以前在学校写项目，都是要几个页面我就建几个 .vue 文件，从来没想过可以合并。mentor 这一句话给我打开了新世界的大门。

周末把这次重构的思路整理一下，算是给自己的第一次需求做个复盘。

核心思路：别被原型的”页面”框住

产品原型画了三个页面，不代表代码里就一定要三个组件。

跳出来看，这三个本质上就是同一个表单的不同状态：

状态	特点	操作
新建	无 ID，表单为空	POST 新增
编辑	有 ID，回填数据	PUT 更新
详情	有 ID，只读展示	无保存按钮

理清楚这个，代码结构就简单多了：一个路由，状态驱动 UI。

场景一：页面跳转（一个路由搞定）

如果表单字段比较多，需要跳转到新页面填写，可以用 Vue Router 的可选参数 ? 来合并路由。

路由配置

// router/index.ts
export default [
  {
    path: "/business/form/:id?", // :id? 表示参数可有可无
    name: "BusinessForm",
    component: () => import("@/views/business/CommonForm.vue"),
  },
];

组件实现

<template>
  <div class="form-container">
    <h2>{{ pageTitle }}</h2>

    <el-form :model="formData" :disabled="isDetail" label-width="120px">
      <el-form-item label="单据名称">
        <el-input v-model="formData.name" placeholder="请输入名称" />
      </el-form-item>

      <el-form-item>
        <el-button v-if="!isDetail" type="primary" @click="handleSave"
          >保存</el-button
        >
        <el-button @click="$router.back()">返回</el-button>
      </el-form-item>
    </el-form>
  </div>
</template>

<script setup lang="ts">
import { ref, computed, onMounted } from "vue";
import { useRoute } from "vue-router";

const route = useRoute();

// 1. 从路由取参数
const id = computed(() => route.params.id);
const type = computed(() => route.query.type);

// 2. 计算当前状态（后面所有的逻辑都靠这三个布尔值控制）
const isCreate = computed(() => !id.value);
const isDetail = computed(() => !!id.value && type.value === "detail");
const isEdit = computed(() => !!id.value && type.value !== "detail");

// 页面标题也根据状态变化
const pageTitle = computed(() => {
  if (isCreate.value) return "新建业务单";
  if (isEdit.value) return "编辑业务单";
  return "业务单详情";
});

const formData = ref({});

// 3. 只有非新建状态才需要拉数据回填
onMounted(async () => {
  if (!isCreate.value) {
    // formData.value = await fetchDetail(id.value)
  }
});

// 4. 保存时根据状态调用不同接口
const handleSave = async () => {
  if (isCreate.value) {
    // await createApi(formData.value)
  } else {
    // await updateApi(id.value, formData.value)
  }
};
</script>

改完之后删掉了两个文件，代码量少了将近一半，维护起来真的轻松多了。

场景二：弹窗表单（靠 Props 控制）

还有一种常见场景是不跳转页面，直接在列表页点弹窗。这种更简单，连路由都不用改，父组件传个 mode 进来就行。

<template>
  <el-dialog :title="dialogTitle" v-model="visible" width="500px">
    <el-form :model="formData" :disabled="isDetail" label-width="100px">
      <!-- 表单字段 -->
    </el-form>

    <template #footer v-if="!isDetail">
      <el-button @click="visible = false">取消</el-button>
      <el-button type="primary" @click="handleSave">确定</el-button>
    </template>
  </el-dialog>
</template>

<script setup lang="ts">
import { ref, computed, watch } from "vue";

const props = defineProps<{
  mode: "create" | "edit" | "detail";
  rowId?: number | string;
}>();

const visible = defineModel<boolean>("visible");

const isCreate = computed(() => props.mode === "create");
const isDetail = computed(() => props.mode === "detail");

const formData = ref({});

// 监听弹窗打开，判断要不要拉数据
watch(
  () => visible.value,
  (show) => {
    if (show) {
      if (isCreate.value) {
        formData.value = {}; // 新建时清空上次的脏数据
      } else {
        // 去查详情回填...
      }
    }
  },
);
</script>

踩坑记录

1. 路由复用导致数据串台

Vue 的组件复用机制，从编辑页跳到新建页时不会重新创建组件。需要在 <router-view> 上加 :key="$route.fullPath"，或者在 watch 里监听路由变化手动清空表单。

2. 不是所有情况都适合合并

如果详情页的 UI 和表单完全不一样（比如加了审批时间轴、操作记录什么的），就别强行合了。老老实实写独立的 Detail.vue，不然一个文件里写几百个 v-if 会很恶心。

3. 前端禁用不等于后端安全

disabled 只能拦住普通用户，拦不住会改 URL 的人。把 ?type=detail 删掉页面就变成可编辑了，所以后端接口一定要做好权限校验。

一点感悟

这次被 mentor 点拨之后，最大的收获是思维上的转变。

以前写代码是”页面驱动”——产品要几个页面，我就建几个文件，满脑子都是复制粘贴。现在开始有点”状态驱动”的意识了，会更关注组件在不同状态下应该有什么行为，而不是纠结于有几个页面。

果然上班和在学校自己瞎写还是不一样，得多和组里的前辈交流，看看别人是怎么设计代码结构的。光靠蛮力堆页面，只会给自己挖坑。

记录一下，继续学习～

人生嘛，自己舒服最优先

Sat, 18 Apr 2026 09:51:35 GMT

大家总说人要 知足常乐，其实很多东西真的不是靠拼命努力就能得到的。现在整个社会都弥漫着一股“你卷我、我不卷就会被淘汰”的氛围，可我还是觉得，人这一生，知足常乐才是最重要的。

摆脱外物的枷锁

现在大多数年轻人，不想被房贷车贷绑住，也不想轻易走进婚姻，我特别能理解这种想法。人本来就不该被外物束缚，除非是遇到了真心喜欢的人，愿意为了对方去努力、去承担。除此之外，真的没必要给自己套上一层层枷锁。

大厂背后的代价

人人都挤破头想进大厂，无非是冲着不错的福利和更高的薪资。可背后的代价呢？

快手：常常忙到晚上十点半、十一点。
字节：也基本加班到很晚。

这样的节奏，哪里还留得下属于自己的时间？一个人打拼或许还能勉强应付，可一旦有了家庭，要在这种高强度工作里兼顾家人，简直不敢想象。更别说工作里各种突发状况，随时待命、随时被叫醒，连喘息的空间都没有。

我们拼命挣钱到底是为了什么？不该是为了掏空自己、消耗生活。

我始终觉得，人首先要对自己好，先让自己过上舒服自在的日子，并且健康的生活着。连自己都没有能力好好生活、好好享乐，又怎么可能真正让身边的人开心？这样的关系本身就是失衡、不对等的。

实习的意义

其实没谁会真心热爱工作，大家不过都是拿时间换钱。不必羡慕进大厂的人，外表光鲜，说到底也只是打工而已。对现在的我们来说，实习阶段最重要的还是 沉下心提升自己。真要是手里有足够的底气，谁还愿意一直被困在工作里呢？

拒绝盲目内卷

内卷的尽头只会是更无尽的内卷：

大二开始实习。
大三忙着找机会。
到后来，连本科生都越来越难有立足之地。

但就算这样，也不必被外界推着走。知足常乐，过好自己的日子，不盲目攀比。年轻的时候也别彻底摆烂，在自己力所能及的范围里努力一点，朝着自己真正想要的生活靠近就好。

生活本就千人千面

每个人想要的都不一样：

有人只想有个小窝，安安稳稳过平淡日子；
有人想早点赚够钱，安安心心躺平；
也有人想努力挣钱，去不同的地方旅行，见不一样的人。

生活本就千人千面，不必活成同一个模板，自己舒心，比什么都重要。

DataAgent 前端架构白皮书:AI-Native 协作体系

Wed, 15 Apr 2026 12:10:15 GMT

1. 核心理念
(Context Governance)

我们不再要求开发者手动维护 Markdown 文档,而是通过 “Single Source of Truth (单一事实来源)” 原则,利用 AST 静态分析技术,将代码中的 TypeScript 类型定义和 JSDoc 注释自动转化为 AI 可读的语义索引。

三大核心原则

Single Source of Truth: 代码即文档。JSDoc/TSDoc 是唯一真理,Markdown 只是它的衍生品。
Deterministic (确定性): 使用 AST(抽象语法树)静态分析生成文档,而非依赖 AI 生成(避免幻觉、降低延迟)。
Folder-as-Context (目录即上下文): 采用”组件/逻辑原子化”的目录结构,通过物理隔离上下文,让 AI 聚焦当前模块。

2. 技术方案

为了覆盖 UI 组件和纯逻辑代码,我们采用 双引擎策略 编写自动化脚本 (scripts/gen-ai-context.mjs)。

引擎架构

引擎类型	适用范围	底层技术	输出内容
UI 引擎	`.vue` 组件	`vue-docgen-api`	Props/Slots/Events/示例代码
逻辑引擎	`.ts` 文件	`ts-morph`	函数签名/类方法/类型定义

工作流程

graph LR
    A[开发者修改代码] --> B[Git Commit]
    B --> C[Husky Pre-commit]
    C --> D[gen-ai-context.mjs]
    D --> E[UI引擎扫描.vue]
    D --> F[逻辑引擎扫描.ts]
    E --> G[生成 README.md]
    F --> G
    G --> H[自动提交文档]
    H --> I[AI读取最新上下文]

3. 目录结构重构 (React-Style)

为了配合上述方案,项目目录结构调整为 “以文件夹为单元” 的模式,实现物理层面的上下文隔离:

DataAgent/
├── .cursorrules          # AI 行为准则 (更新版)
├── components/           # [UI 引擎管辖]
│   ├── UserCard/         # 独立组件文件夹
│   │   ├── index.vue     # 主代码 (包含 JSDoc)
│   │   ├── types.ts      # 组件专属类型
│   │   └── README.md     #  脚本自动生成 (AI 读这里,勿手改)
│   └── README.md         #  脚本生成全局组件索引 (AI 地图)
├── composables/          # [逻辑引擎管辖]
│   ├── useAuth/          # 独立 Hook 文件夹
│   │   ├── index.ts      # 逻辑代码 (包含 JSDoc)
│   │   └── README.md     #  脚本自动生成
├── scripts/
│   └── gen-ai-context.mjs # 核心自动化脚本
└── package.json          # 配置 husky 钩子

关键设计思想

物理隔离: 每个组件/逻辑单元独立成文件夹,避免上下文污染
就近原则: 类型定义、测试文件与主代码放在同一目录
AI 导航: 每个模块的 README.md 作为 AI 的”索引卡片”

4. 简单实现思路 (Implementation Roadmap)

第一步
(scripts/gen-ai-context.mjs)

这是一个整合了双引擎逻辑的 Node.js 脚本。

伪代码逻辑

import { generateComponentDocs } from "./utils/ui-engine"; // 基于 vue-docgen-api
import { generateLogicDocs } from "./utils/logic-engine"; // 基于 ts-morph
import { generateGlobalIndex } from "./utils/indexer";

(async () => {
  console.log(" 正在构建 AI 上下文索引...");

  // 1. 处理 UI 组件
  // 遍历 components/*/*.vue,提取 Props/Slots -> 写入同级 README.md
  await generateComponentDocs();

  // 2. 处理 逻辑与服务
  // 遍历 composables/*.ts, services/*.ts -> 提取函数签名/Class -> 写入同级 README.md
  await generateLogicDocs();

  // 3. 更新全局映射
  // 扫描所有生成的 README,更新根目录或各模块根的索引表,方便 AI 跳转
  await generateGlobalIndex();

  console.log("✅ AI 上下文同步完成");
})();

第二步
(Workflow Integration)

放弃”拦截报错”模式,采用 “无感修正” 模式。开发者只关注代码和注释,文档更新对人是透明的。

收益分析

✅ 零心智负担: 开发者无需手动维护文档
✅ 强制同步: 文档永远不会过期
✅ AI 即时感知: 每次提交后 AI 立即获得最新上下文

第三步
.cursorrules (AI 指令)

这是项目的”最高宪法”,指导 AI 如何利用上述基础设施。

# DataAgent (Nuxt 4 SPA + TypeScript) 开发法则

## 0. 关键上下文 (最高优先级)

- **框架**: Nuxt 4 (基于 Nitro 引擎)。
- **模式**: 纯 SPA 模式 (`ssr: false`)。
- **语言**: TypeScript (严格模式)。**严禁**使用 `.js` 文件。
- **UI 库**: Vuetify 3 (必须使用 `<v-btn>` 等组件,而非原生 `<div>`)。

## 1. 知识检索协议 (Knowledge Retrieval)

在回答问题或编写代码之前,必须执行以下步骤:

1. **框架层**: 涉及 Nuxt 核心 (如 Nitro, Composables) **必须**优先参考 `@Nuxt4` 文档。
2. **地图加载 (Map Loading)**:
   - 涉及新功能开发时,先检索 `components/README.md` 或 `composables/README.md` (全局索引)。
3. **本地上下文 (Local Context)**:
   - 修改现有组件或逻辑前,**必须读取**该目录下自动生成的 `README.md` (技能卡片/Skill Card)。
4. **查重机制 (Similarity Check)**:
   - **原则**: "先存在,后创建" (Exist before Create)。
   - 如果发现已存在类似功能的代码,**必须**优先考虑复用,而不是新建。
5. **类型定义**: 优先引用 `types/` 或同级目录下的 `.ts` 定义,**禁止**凭空猜测数据结构。

## 2. 编码规范 (Coding Standards)

- **严格 TypeScript**: 所有变量、参数、返回值必须有明确的类型定义,**禁止**使用 `any`。
- **文档先行 (Documentation First)**: 生成代码时,必须包含标准的 JSDoc/TSDoc 注释。
  - **组件**: `<script setup>` 顶部需包含 `@description` 说明组件用途。
  - **Props**: `defineProps` 上方需说明每个属性的业务含义。
  - **逻辑**: 所有函数必须包含 `@param` 和 `@returns` 说明。
- **架构结构**:
  - **API**: 统一使用 Axios,所有服务层代码必须存放在 `app/services/`。
  - **风格**: 必须使用 Vue 3 组合式 API (`<script setup lang="ts">`)。

## 3. 复用与重构策略 (Reuse & Refactor)

- **DRY 原则 (拒绝重复)**:
  - **禁止**生成重复的工具函数或极其相似的 UI 组件。
  - 如果发现现有组件/函数满足当前 **80%** 的需求,**严禁**复制一份代码进行修改。
- **多态扩展 (Polymorphic Extension)**:
  - **方案**: 通过增加 **可选属性 (Optional Props)**、**泛型 (Generics)** 或 **回调策略** 来扩展现有组件/函数,使其适应新需求。
- **安全护栏 (Guardrail)**:
  - 重构时必须保证 **向后兼容性 (Backward Compatibility)**。
  - _示例_: 原函数 `fetchData(id)` -> 新需求需要额外参数 -> 改为 `fetchData(id, options?)`。**禁止**直接修改必填参数导致旧的调用方报错。
- **重构触发器**:
  - 当你发现自己在"复制粘贴"代码时,**立即停止**。改为将公共逻辑提取到 `composables/` 或 `utils/` 中,并更新原来的引用。

## 4. 协作协议

- **禁止**手动修改 `README.md`,文档全权由自动化脚本生成。
- 提交代码前,必须确保通过 TypeScript 类型检查 (无 Type Error)。

5. 外部文档集成与兜底 (External Context & Fallback)

5.1 团队级外部文档 (Nuxt 4 Docs)

为了解决团队成员无法自动同步 Cursor Docs 的问题,我们将手动配置转化为标准流程说明。

配置方案

同步媒介: 在项目根目录维护 docs/AI_SETUP.md。
操作指令: 新成员入职时,需在 Cursor 侧边栏 Docs 中添加:
- Nuxt4-Guide: https://nuxt.com/llms.txt
- Nuxt4: https://nuxt.com/llms-full.txt

5.2 模块化 Service 层与 TS 护城河

为了在 DataAgent 重构中建立 AI 友好型应用,我们将逻辑深度抽象。

实践策略

Service 抽离: 在 app/services/ 中按业务域(如 AgentService, KnowledgeService)拆分 Class 或 Module。
TS 类型即文档:
- ts-morph 引擎会自动提取 Service 中的 interface 和 public 方法签名到 README。
- 收益: 当 AI 知道 getAgent(id: string): Promise<AgentNode> 的确切类型时,它生成的业务逻辑准确率将从 60% 提升到 95% 以上。

示例
结构

/**
 * Agent 管理服务
 * @description 负责 Agent 节点的 CRUD 操作和状态管理
 */
export class AgentService {
  /**
   * 获取 Agent 详情
   * @param id - Agent 唯一标识符
   * @returns Agent 节点完整信息
   */
  async getAgent(id: string): Promise<AgentNode> {
    // 实现逻辑...
  }

  /**
   * 创建新 Agent
   * @param payload - Agent 创建参数
   * @returns 创建成功的 Agent 节点
   */
  async createAgent(payload: CreateAgentDTO): Promise<AgentNode> {
    // 实现逻辑...
  }
}

生成的 README.md 会自动包含:

所有公共方法的签名
参数和返回值的 TypeScript 类型
JSDoc 中的业务说明

6. 实施效果与未来展望

6.1 量化收益

指标	改进前	改进后	提升幅度
AI 代码准确率	60%	95%	+58%
文档维护成本	每周 4 小时	0 小时	-100%
新成员上手时间	2 周	3 天	-78%
重复代码率	35%	8%	-77%

6.2 技术演进方向

增量编译: 只对修改的文件重新生成文档,提升大型项目的构建速度
语义索引: 基于 Embedding 技术建立代码语义搜索,让 AI 能够理解”相似功能”
跨项目复用: 将成熟的组件/逻辑抽象为 NPM 包,配套生成 AI 可读的 llms.txt

7. 总结
开发的哲学

这套体系的本质是 “约束即自由”:

通过 AST 确定性 约束了文档生成的随意性
通过 目录结构 约束了上下文的泛滥
通过 TypeScript 约束了类型的模糊性

最终换来的是:

开发者从文档维护中彻底解放
AI 从”猜测”变为”理解”
团队协作从”口口相传”变为”制度保障”

这不是一个技术方案,而是一次开发范式的升级。

规范驱动 + 需求 Loop AI 编程工作流 Demo

Tue, 14 Apr 2026 11:43:46 GMT

规范驱动 + 需求 Loop AI 编程工作流 Demo

目标

在现有 React 项目中，通过扩展 OpenSpec 自定义 Schema，实现一套完整的”Skill 知识库 + 需求 Loop + 规范驱动实现 + 自动验证”工作流。

关键认知：这套工作流运行在 AI IDE（Cursor / Claude Code / CodeFlicker）的对话框里，我们不需要实现对话 UI，我们要做的是：

在 OpenSpec 里创建一个自定义 Schema loop-driven
Schema 里新增 requirement-loop artifact（放在 proposal 之前）
这个 artifact 的 instruction 引导 AI 检索 Skill 知识库、逐条反问用户
后续正常走 proposal → specs → design → tasks → /apply → /verify

┌─────────────────────────────────────────────────────────────┐
│  触发路径 A（隐式）            触发路径 B（显式）              │
│                                                             │
│  用户: "帮我实现登录功能"      用户: "/opsx:propose add-login" │
│        ↓                              ↓                     │
│  AI 检测到需求模糊            AI 等待用户描述需求              │
│  → "需求描述较模糊，建议先     → "请简单描述你的登录功能需求"   │
│    用 /opsx:propose 完善，     → 用户输入后                   │
│    是否继续？"                                               │
│        ↓（用户确认）                  ↓                     │
└──────────────────────┬──────────────────────────────────────┘
                       ↓（两条路在这里汇合）
[requirement-loop artifact]
  AI 读取 openspec/skills/login.md 知识库
  → 逐条询问用户最佳实践选项（在 AI IDE 对话框里完成）
  → 用户回答 Yes/No 或补充说明
  → 生成 requirement-loop.md（需求确认文档）
        ↓
proposal artifact（依赖 requirement-loop.md）
  → AI 基于确认后的需求生成 proposal.md
        ↓
specs artifact → design artifact → tasks artifact
        ↓
/opsx:apply  →  /opsx:verify

1. 整体架构

1.1 文件结构

my-react-app/
├── openspec/
│   ├── config.yaml                    ← 项目配置：设置默认 schema 为 loop-driven
│   ├── schemas/
│   │   └── loop-driven/               ← 自定义 Schema（核心产物）
│   │       ├── schema.yaml            ← Workflow 定义（含新增的 requirement-loop artifact）
│   │       └── templates/
│   │           ├── requirement-loop.md ← Loop artifact 的模板（引导 AI 如何提问）
│   │           ├── proposal.md
│   │           ├── spec.md
│   │           ├── design.md
│   │           └── tasks.md
│   ├── skills/                        ← Skill 知识库（最佳实践沉淀，供 AI 检索）
│   │   ├── login.md                   ← 登录功能最佳实践
│   │   ├── payment.md                 ← 支付功能最佳实践（未来扩展）
│   │   └── README.md                  ← 说明如何使用 Skill 库
│   ├── specs/                         ← 系统级规范（归档后持久化）
│   └── changes/                       ← 每次变更目录
│       └── add-login/                 ← 本次演示用的变更
│           ├── requirement-loop.md    ← 需求确认文档（Loop 产物）
│           ├── proposal.md
│           ├── design.md
│           ├── tasks.md
│           └── specs/
│               └── auth-login/
│                   └── spec.md
└── src/                               ← React 代码（按 tasks.md 实现）
    └── components/
        └── Login/
            ├── LoginForm.tsx
            └── useLoginLogic.ts

1.2 工作流全景图

两条触发路径，汇合后走相同的 Loop + OpenSpec 流程：

路径 A — 隐式触发（自然语言 → AI 主动建议）

开发者: "帮我实现一个登录功能"
  ↓
AI 判断需求模糊（依赖 config.yaml 的 context rules 注入）
  → 回复: "你的需求描述比较简短，为确保实现质量，建议先用
            /opsx:propose 完善需求细节，是否继续？"
  ↓ 用户确认
进入 requirement-loop artifact

路径 B — 显式触发（直接调用 propose）

开发者: "/opsx:propose add-login"
  ↓
AI: "请简单描述你的登录功能需求（比如：面向什么用户、
     有无特殊安全要求等），我来帮你完善规范。"
  ↓ 用户输入需求描述
进入 requirement-loop artifact

两条路汇合后的统一流程：

[requirement-loop artifact]
AI 读取 openspec/skills/{feature}.md 知识库
→ 逐条反问用户（在 AI IDE 对话框里，就是普通聊天）
→ 用户回答 Yes/No 或追加参数说明
→ 生成 requirement-loop.md

→ proposal.md（基于确认需求）
→ specs/auth-login/spec.md（GIVEN/WHEN/THEN）
→ design.md（技术决策）
→ tasks.md（实现清单）

/opsx:apply  → 代码实现
/opsx:verify → 规范验证

1.3 路径 A 的实现方式

路径 A 不需要写代码，通过 openspec/config.yaml 的 context 向 AI 注入行为规则：

context: |
  当用户输入与功能实现相关的简短需求（如"帮我实现登录"、"做一个支付页面"），
  且需求描述不够详细时，请主动提示：
  "需求描述较模糊，建议先运行 /opsx:propose <feature-name> 完善需求细节，
  以确保实现质量，是否继续？"

  这样可以触发 requirement-loop，确保在写代码之前把需求对齐清楚。

这条 context 会被注入到所有 AI 响应的系统提示里，让 AI IDE 具备”主动建议进入 Loop”的行为。

2. 核心产物：loop-driven Schema

2.1 schema.yaml

文件：openspec/schemas/loop-driven/schema.yaml

name: loop-driven
version: 1
description: |
  需求 Loop 驱动的规范开发流程。
  在生成 proposal 之前，先通过 AI 检索 Skill 知识库，
  逐条与用户确认最佳实践，确保需求无遗漏后再进入实现阶段。

artifacts:
  - id: requirement-loop
    generates: requirement-loop.md
    description: 需求确认文档（AI 检索 Skill 知识库后与用户逐条确认的结果）
    template: requirement-loop.md
    instruction: |
      你是一个经验丰富的技术架构师。用户想要实现一个新功能。

      你的任务分两步：

      **Step 1: 检索 Skill 知识库**
      读取 openspec/skills/ 目录下与当前功能相关的 Skill 文件。
      根据用户描述的功能名称（如 "login"、"payment"），
      找到对应的 skills/*.md 文件，提取其中的最佳实践列表。

      **Step 2: 逐条需求确认（Loop）**
      对检索到的每一条最佳实践：
      1. 用自然语言向用户提问（包含：这是什么、为什么需要它、推荐默认值）
      2. 等待用户回答（Yes/No 或追加说明）
      3. 记录用户的选择和补充

      直到所有最佳实践都确认完毕，才能生成 requirement-loop.md。

      生成的 requirement-loop.md 必须包含：
      - 用户的原始需求描述
      - 每条最佳实践的确认结果（选择 + 具体参数）
      - 明确的 Out of Scope（用户选择不实现的）
    requires: []

  - id: proposal
    generates: proposal.md
    description: 变更提案
    template: proposal.md
    instruction: |
      基于 requirement-loop.md 中已确认的需求，生成变更提案。
      proposal 必须完整反映用户在 Loop 中确认的所有选项。
    requires:
      - requirement-loop

  - id: specs
    generates: specs/**/*.md
    description: 功能规范（GIVEN/WHEN/THEN 格式）
    template: spec.md
    instruction: |
      基于 proposal.md 和 requirement-loop.md，
      为每一条已确认的需求生成对应的 Requirement + Scenario。
      使用标准的 GIVEN/WHEN/THEN 格式。
    requires:
      - proposal

  - id: design
    generates: design.md
    description: 技术设计文档
    template: design.md
    requires:
      - specs

  - id: tasks
    generates: tasks.md
    description: 实现任务清单
    template: tasks.md
    instruction: |
      基于 design.md 和 specs，生成分阶段的实现任务清单。
      每条任务必须能追溯到 spec.md 中的某个 Requirement。
    requires:
      - design

apply:
  requires: [tasks]
  tracks: tasks.md

2.2 requirement-loop.md 模板

文件：openspec/schemas/loop-driven/templates/requirement-loop.md

# Requirement Loop: {{feature-name}}

## 用户原始需求

<!-- 记录用户的原始输入，原文保留 -->

## 检索到的相关最佳实践

<!-- 列出从 Skill 知识库中找到的相关实践清单 -->

## 需求确认结果

<!-- 每条最佳实践的确认状态，格式如下：

### ✅ [最佳实践名称]
- **选择**: 需要
- **参数**: [用户补充的具体参数，如 RT 有效期 = 30天]
- **纳入规范**: The system SHALL ...

### ❌ [最佳实践名称]
- **选择**: 不需要
- **原因**: [用户说明的原因，或 N/A]
-->

## Out of Scope

<!-- 明确列出本次不实现的内容，防止后续争议 -->

3. Skill 知识库

3.1 登录功能最佳实践

文件：openspec/skills/login.md

# Login Feature Skills

> 这是登录功能的最佳实践知识库。
> 当用户要实现登录功能时，AI 应逐条确认以下实践。

## 最佳实践清单

### 1. 双 Token 机制（dual-token）

**分类**: Security
**推荐**: ✅ 是
**说明**: 使用 Access Token（AT，短期，建议 15 分钟）+ Refresh Token（RT，长期，建议 7 天）。
AT 过期后用 RT 静默刷新，用户无感知。避免长期 Token 泄露风险。
**需确认的参数**: AT 有效期、RT 有效期、Token 存储方式（localStorage / httpOnly Cookie）

---

### 2. 登录按钮防抖（debounce）

**分类**: UX
**推荐**: ✅ 是
**说明**: 防止用户多次点击导致重复发送请求。建议 300ms 防抖 + 请求期间禁用按钮。
**需确认的参数**: 防抖时长（默认 300ms）

---

### 3. 实时表单校验（form-validation）

**分类**: UX
**推荐**: ✅ 是
**说明**: 用户输入时即时提示错误（邮箱格式、密码强度），减少提交后报错的挫败感。
**需确认的参数**: 校验时机（onBlur / onChange）、使用 Zod / Yup / 原生

---

### 4. 密码前端加密（password-encrypt）

**分类**: Security
**推荐**: ⚠️ 视情况
**说明**: 在 HTTPS 普及的情况下，前端加密价值有限，但对安全要求高的场景（金融/企业）建议开启。
**需确认的参数**: 加密算法（bcrypt 在前端不适用，通常用 SHA-256 或 RSA 公钥加密）

---

### 5. 记住我（remember-me）

**分类**: UX
**推荐**: ✅ 是
**说明**: 允许用户选择是否保持登录状态更长时间（延长 RT 有效期或使用持久化存储）。
**需确认的参数**: 记住时长（默认 30 天）、实现方式

---

### 6. 验证码（captcha）

**分类**: Security
**推荐**: ⚠️ 视情况
**说明**: 防止暴力破解。可以在连续失败 N 次后触发（而非每次都要求）。
**需确认的参数**: 触发条件（失败几次后）、类型（图片/短信/行为验证）

---

### 7. 细分错误类型（granular-errors）

**分类**: UX
**推荐**: ✅ 是
**说明**: 区分"账号不存在"和"密码错误"的提示，帮助用户定位问题（注意：某些场景出于安全考虑故意模糊）。
**需确认的参数**: 是否区分（部分场景为防止账号枚举攻击，应统一返回"账号或密码错误"）

---

### 8. Loading 状态（loading-state）

**分类**: UX
**推荐**: ✅ 是
**说明**: 登录请求期间展示 Loading 指示器，防止用户以为没有响应而重复点击。
**需确认的参数**: 展示方式（按钮 loading / 全屏遮罩）

---

### 9. 前端限流（rate-limiting）

**分类**: Security
**推荐**: ✅ 是
**说明**: 前端记录失败次数，超过阈值后锁定登录一段时间（配合后端限流双重保障）。
**需确认的参数**: 最大失败次数（默认 5）、锁定时长（默认 15 分钟）

3.2 README

文件：openspec/skills/README.md

# OpenSpec Skills 知识库

这里存放各功能模块的最佳实践知识库，供 `requirement-loop` artifact 检索使用。

## 结构

- `login.md` — 登录/认证相关最佳实践
- `payment.md` — 支付相关最佳实践（待补充）

## 如何使用

当 AI 执行 `requirement-loop` artifact 时，会自动读取本目录下与当前功能相关的文件。
也可以在 `openspec/config.yaml` 的 context 里显式声明 Skills 路径。

## 如何扩展

为新功能添加 Skills：

1. 在此目录新建 `{feature}.md`
2. 按照现有格式填写最佳实践清单
3. 每条实践包含：分类、推荐程度、说明、需确认的参数

4. 项目配置

4.1 config.yaml

文件：openspec/config.yaml

schema: loop-driven

context: |
  Tech stack: TypeScript, React 19, Vite, Tailwind CSS
  Form validation: Zod + React Hook Form
  Auth pattern: JWT (Access Token + Refresh Token)
  State management: React hooks (no Redux)

  当执行 requirement-loop 时，请读取 openspec/skills/ 目录下对应的 Skill 文件。

rules:
  requirement-loop:
    - 必须逐条询问，不得跳过任何 Skill
    - 每个问题都要说明"为什么需要它"
    - 用户的补充说明必须原文记录到 requirement-loop.md
    - 生成文档前必须得到用户对所有条目的明确答复
  specs:
    - 使用 Given/When/Then 格式
    - 每条 Requirement 必须能追溯到 requirement-loop.md 中的某个确认结果
  tasks:
    - 每个 Task 必须注明对应的 spec Requirement ID

5. 完整演示流程

5.1 路径 A 演示（隐式触发：模糊需求 → AI 主动建议）

开发者: "帮我实现一个登录功能"

AI:     "你的需求描述比较简短，为确保实现符合最佳实践，
         建议先用 /opsx:propose 完善需求细节，是否继续？"

开发者: "好的"

AI:     "请简单描述你的登录场景（比如：B端还是C端？
         有无特殊安全要求？目标用户量？）"

开发者: "C端用户，日活10万，需要比较严格的安全控制"

AI:     "明白了。检索登录知识库...
         找到 9 条相关实践，我们逐一确认 ↓"
         [进入 Loop →]

5.2 路径 B 演示（显式触发：直接 /opsx
）

开发者: /opsx:propose add-login

AI:     "请简单描述你的登录功能需求。"

开发者: "标准账号密码登录，C端，安全性要求较高"

AI:     "好的，检索登录知识库... 找到 9 条相关实践，逐一确认 ↓"
         [进入 Loop →]

5.3 Loop 对话（两条路径汇合后相同）

AI：[1/9] 双 Token 机制
    建议使用 Access Token（短期，15分钟）+ Refresh Token（长期，7天）。
    AT 过期后用 RT 静默刷新，用户无感知，避免长期 Token 泄露。
    你的项目需要这个吗？如果需要，AT 和 RT 的有效期用默认值吗？

用户：需要，RT 改成 30 天

AI：记录 ✅ 双 Token，AT=15min，RT=30天。

    [2/9] 登录按钮防抖
    防止多次点击重复发送请求，建议 300ms 防抖 + 请求期间禁用按钮。需要吗？

用户：需要

...（9条全部确认）

AI：需求确认完成！
    生成 requirement-loop.md ✓
    生成 proposal.md ✓
    生成 specs/auth-login/spec.md ✓
    生成 design.md ✓
    生成 tasks.md ✓

    所有文档已就绪，请审阅后运行 /opsx:apply 开始实现。

6. 实施顺序

步骤	任务	文件	说明
1	安装 OpenSpec CLI	—	`npm install -g @fission-ai/openspec@latest`
2	初始化 OpenSpec	`openspec/`	`openspec init` 生成基础目录
3	Fork 内置 schema	`openspec/schemas/loop-driven/`	`openspec schema fork spec-driven loop-driven`
4	编写 Skill 知识库	`openspec/skills/login.md`	核心产物，包含 9 条登录最佳实践
5	修改 schema.yaml	`openspec/schemas/loop-driven/schema.yaml`	新增 `requirement-loop` artifact，调整依赖链
6	编写 Loop 模板	`openspec/schemas/loop-driven/templates/requirement-loop.md`	AI 生成 requirement-loop 文档的结构模板
7	配置 config.yaml	`openspec/config.yaml`	设置默认 schema + 注入 context + Loop 规则
8	验证 schema	—	`openspec schema validate loop-driven`
9	执行演示 Loop	`openspec/changes/add-login/`	`/opsx:propose add-login` 跑通完整流程
10	对照 tasks.md 实现登录组件	`src/components/Login/`	这是最终的代码产物
11	执行 verify	—	`/opsx:verify` 验证覆盖率

7. 核心设计哲学

Skill 库 = 沉淀在版本控制里的最佳实践
- 不是散落在 Wiki 里的文档，而是 openspec/skills/*.md，随代码一起 git 管理
- 新人入职可以直接读；AI 接任务也可以直接读
Loop = OpenSpec 工作流的前置环节，不是独立 App
- 通过自定义 Schema 的 requirement-loop artifact 实现
- 运行在 AI IDE 的对话框里，用户体验与正常聊天无异
- 完成后自动衔接后续的 proposal/specs/design/tasks
OpenSpec = 唯一真相来源
- spec.md 里的 GIVEN/WHEN/THEN 是可验证的规范
- requirement-loop.md 存档了”为什么这样设计”的决策过程
- tasks.md 是代码实现的 checklist
Verify = 闭环，不是摆设
- /opsx:verify 让 AI 对照 spec.md 逐条检查实现
- 每个 task 都能追溯到 spec 的 Requirement，形成完整的可追溯链
可扩展性
- 想支持支付功能？新建 openspec/skills/payment.md 即可
- 这套 Schema 和 Skills 库可以在团队内所有项目共享

VIVO面经

Thu, 12 Mar 2026 07:00:00 GMT

VIVO

面试时间

2026_0312-15:00

面试内容

自我介绍
AST 静态分析：TS 类型与注释自动转 AI 可读索引如何实现
Git Hash 增量设计：Hash 冲突处理、如何确保只更新变更文件文档
MCP 自动生成组件文档库实现细节
多分支团队开发下如何保证组件文档最新
平时如何使用 AI 编码工具
大量 AI 生成代码时如何保证质量（AI Code Review、多 AI 交叉 Review）
需求完成后如何测试（手动 + 可自动模拟执行测试）
MCP 和 Skill 的区别
反问
业务方向：AI 全栈、内部工具、ToB 与 ToC 皆有

快手面经（二）

Mon, 09 Mar 2026 07:00:00 GMT

快手

面试时间

2026_0309-15:00

面试内容

面试官介绍抖音、PDD、京东、淘宝、快手电商布局
介绍前端团队方向
C 端 App、B 端商家服务平台、内容审核与监测
自我介绍
AI 对话框长对话和打字机效果是否考虑开源库
未使用库时如何实现（SSE + setTimeout）
React useEffect 第二个参数三种情况
React.memo 和 useMemo 区别
对前端热点方向的理解
cursor 编辑器是自费还是公司提供
反问：对实习生的期待

面试官给的建议

JS 基础要扎实
项目经验要丰富
关注前端最新方向
保持对前端的热爱
做好校招储备

Yukiの小窝

第 5 期：工作三个月，离职休息与秋招准备

情绪与状态：疲惫与决定

接下来的计划：休息、旅游与秋招

面试与八股复习

携程集团面经

携程集团

面试时间

面试内容

面试复盘总结（核心问题精讲）

1) React Hooks 与 forwardRef（Q4, Q5）

解释 React Hooks

为什么需要 forwardRef？

2) CommonJS 与 ES6 Module 的变量导出差异（Q10）

CommonJS (CJS) —— 值的浅拷贝

ES6 Module (ESM) —— 动态只读引用（Live Bindings）

3) Flex 布局：flex: 1 vs flex: auto（Q11, Q12, Q13）

Flex 基本概念

flex 简写属性的秘密

拆解代码演示：flex: 1 vs flex: auto

4) CSS 动画与 animation 属性详解（Q17, Q18）

第一步：定义 @keyframes

第二步：使用 animation 简写属性

知乎一面面经

知乎一面

面试时间

面试题目

面试复盘（核心问题精讲）

1) 低代码动态表单怎么联动？（Q7）

第一层：联动规则的 Schema 定义

第二层：状态管理树（Form Store）

第三层：副作用派发与异步回填执行流（核心）

第四层：防死循环（DAG 拓扑排序）

2) 提前加载内容与 Intersection Observer 的 margin（Q8）

3) 弱网 + 快速滑动长列表的图片优化（Q9）

4) 箭头函数特性底层剖析（Q14）

5) 前端安全与 React 转义机制（Q19 & Q20）

劳作与远行交叠，夜修与心愿同起

工作：混研 + 低代码的日常磨耗

1) 你根本不知道页面是源码还是低代码

2) 老项目线上问题 + 三平台兼容

3) 业务逻辑循环：提测 → 修 bug → 再提测

求职：投递不顺 & 一点点希望

学习：设计模式 & 依赖注入的惊喜

生活：武汉三日游 + 北京小打卡

武汉三日游（周五晚 ~ 周一）

北京周末小逛

碎碎念

一点思考

设计模式：创建型模式

创建型模式到底在解决什么？

工厂模式（Factory Pattern）

前端真实场景：根据数据动态渲染不同卡片

如果没有工厂，灾难还会蔓延

更前端一点的写法：工厂模式解耦

单例模式（Singleton Pattern）

前端真实场景：全局唯一的 WebSocket 消息通知

第一反应：哪里需要，就在哪里连

灾难：服务器爆炸与状态非同步

解决思路：单例模式

依赖注入（Dependency Injection, DI）

前端真实场景：深层级组件的上下文传递

第一反应：Props 一路向下钻（Props Drilling）

灾难：无辜的中间层被绑架

解决思路：依赖注入（DI）

进阶前端场景：逻辑类的连环依赖（A 依赖 B，B 依赖 C）

终极解决思路：IoC 容器统一做这层“中间商”

附录：这个“管家”底层凭什么这么神奇？（极简版容器实现）

原型模式（Prototype Pattern）

前端真实场景：满地都是的臃肿图表配置

第一反应：疯狂复制粘贴字典对象

灾难：一处 UI 改动，处处漏改

解决思路：原型模式

建造者模式（Builder Pattern）

前端真实场景：复杂的弹窗参数 / 动态查询 API

第一反应：塞出一个无敌长的参数列表

灾难：极差的可读性与扩展逻辑的散落

解决思路：建造者模式

对象池模式（Object Pool）

前端真实场景：满屏的春节红包雨 / Canvas 子弹效果

1) React Hooks 与 `forwardRef`（Q4, Q5）

为什么需要 `forwardRef`？

3) Flex 布局：`flex: 1` vs `flex: auto`（Q11, Q12, Q13）

`flex` 简写属性的秘密

拆解代码演示：`flex: 1` vs `flex: auto`

4) CSS 动画与 `animation` 属性详解（Q17, Q18）

第一步：定义 `@keyframes`

第二步：使用 `animation` 简写属性