193577746 (kyriewen)

Claude Code 后天起默认 Auto 模式了——我第一时间改了这 6 个设置

193577746 — Wed, 12 Aug 2026 19:51:40 +0800

刷到 Anthropic 的公告时是周五晚上。大意是：8 月 14 日起，Claude Code 的 Pro、Max 和 Team 用户将默认启用 Auto 模式。

翻译成人话就是——后天开始，Claude Code 不再逐条问你"可以执行这个命令吗？"，而是自己判断安全性后直接执行。修改文件、运行脚本、执行 git 操作，全部自动。

我当时第一反应是打开终端检查了自己的 settings.json。不是因为我觉得 Auto 模式一定会炸，而是因为这件事的默认值变了，意味着你什么都不做的话，行为就变了。

Anthropic 为什么敢这么做

他们给了三个数据：

数据一：97% 的权限提示被无脑批准。

Anthropic 统计了所有 Claude Code 用户的权限操作——每次 Claude 要执行命令时弹出的"Allow?"确认框，97% 的情况下用户直接点了同意。

这意味着那个确认框形同虚设。你以为自己在"审核"，实际上你在条件反射地按回车。

数据二：62% 的用户已经在用 bypassPermissions 或类似设置。

超过一半的付费用户早就主动关掉了权限确认。Claude Code 的六种权限模式里，最严格的 Manual 模式反而是少数人在用。

数据三：1053 人对照实验，Auto 模式比人工审核安全 6.5 倍。

Anthropic 做了一个对照研究——同样的危险命令序列，Auto 模式的内置分类器拦截了89%，而人工逐条审核只拦截了13.6%。

原因很简单：机器不会疲劳，不会在第 47 次"Allow?"的时候走神点了同意。人会。

但是——11% 的漏网率

89% 拦截率的另一面是：有 11% 的危险命令，Auto 模式也没拦住。

这 11% 是什么？根据公开的测试报告，主要是：

看起来像正常操作但实际有副作用的命令（比如rm -rf被包在一个看似无害的脚本里）
涉及环境变量或敏感路径的间接操作
组合命令中的链式危险操作（单独看每步都安全，串起来就危险）

11% 听起来不多，但如果你一天跑 100 次命令，平均每天有 11 次危险操作会被放行。

Auto 模式到底会"自动"做什么

打开 Auto 模式后，Claude Code 会在以下操作上不再询问你：

操作类型	Manual 模式	Auto 模式
读取文件	自动	自动
写入/修改文件	⚠️ 需确认	✅ 自动执行
执行 Bash 命令	⚠️ 需确认	✅ 自动执行（除非触发危险分类器）
git add/commit	⚠️ 需确认	✅ 自动执行
git push	⚠️ 需确认	🔴 分类器拦截（大多数情况）
rm/delete 操作	⚠️ 需确认	🟡 取决于路径和上下文
安装 npm 包	⚠️ 需确认	✅ 自动执行
修改 package.json	⚠️ 需确认	✅ 自动执行

关键变化：文件写入和 Bash 命令执行不再需要你确认。 这意味着 Claude 可以直接改你的代码、直接跑脚本、直接装包——只要它的内置分类器认为"安全"。

我改了哪 6 个设置

看完公告后我做的第一件事不是关掉 Auto 模式（那样就退回到 97% 无脑点同意的状态了），而是在 Auto 模式的基础上加约束。

设置 1：配置 allowedTools 白名单

// .claude/settings.json
{
  "permissions": {
    "allow": [
      "Read",
      "Glob",
      "Grep",
      "Write(src/**)",
      "Edit(src/**)"
    ],
    "deny": [
      "Write(.env*)",
      "Write(*.config.js)",
      "Bash(rm *)",
      "Bash(git push*)"
    ]
  }
}

核心思路：只允许 Claude 自动写入src/目录下的文件。 配置文件、环境变量、根目录文件全部需要确认。这样 Claude 可以自由改业务代码，但碰不了构建配置和敏感文件。

设置 2：锁死.env 和敏感文件

{
  "permissions": {
    "deny": [
      "Read(.env*)",
      "Write(.env*)",
      "Read(**/*secret*)",
      "Read(**/*credential*)",
      "Bash(*SECRET*)",
      "Bash(*TOKEN*)",
      "Bash(*PASSWORD*)"
    ]
  }
}

Auto 模式下 Claude 能读取项目里的任何文件——包括.env。如果你的.env里有数据库密码、API 密钥，Claude 读到之后可能在生成代码时把它们硬编码进去，或者在执行命令时意外暴露。

deny 规则优先级高于 allow，配了 deny 之后即使 Auto 模式也会被拦住。

设置 3：git 操作限制

{
  "permissions": {
    "deny": [
      "Bash(git push*)",
      "Bash(git reset --hard*)",
      "Bash(git checkout -- *)",
      "Bash(git clean*)",
      "Bash(git branch -D*)"
    ]
  }
}

Auto 模式下 Claude 可以自动git add和git commit——这其实挺方便的。但push、reset --hard、强制删除分支这些不可逆操作，必须手动确认。

一个真实案例：上周看到有人发帖说 Claude Code 在 Auto 模式下自动 push 了一个有 debug 日志的 commit 到 main 分支。原因是 Claude 判断"commit+push 是一个完整的工作流"，分类器没有拦截 push 操作。

设置 4：npm install 限制

{
  "permissions": {
    "deny": [
      "Bash(npm install *--global*)",
      "Bash(npx *)",
      "Bash(yarn global*)"
    ],
    "allow": [
      "Bash(npm install)",
      "Bash(npm run *)",
      "Bash(yarn install)",
      "Bash(yarn add *)"
    ]
  }
}

允许 Claude 在项目内装包（npm install、yarn add），但禁止全局安装和 npx 执行。npx 可以下载并执行任意包——这是一个巨大的攻击面。

设置 5：CLAUDE.md 加入硬规则

# CLAUDE.md

## 安全规则（Auto模式下必须遵守）

- 永远不要修改 .env、.env.local 或任何包含环境变量的文件
- 永远不要执行 git push，所有push操作必须由我手动执行
- 永远不要删除文件，如需删除请先列出文件列表等我确认
- 永远不要修改 CI/CD 配置文件（.github/workflows/*, .gitlab-ci.yml）
- 新增依赖时必须说明理由，不要静默安装

CLAUDE.md 是 Claude Code 的行为规则文件。Auto 模式下 Claude 会遵守这些规则——当然，这不是"硬性"限制（settings.json 的 deny 规则才是），但它提供了一层语义级别的防护。

设置 6：开启操作日志

{
  "auditLog": {
    "enabled": true,
    "path": ".claude/audit.log",
    "includeCommands": true,
    "includeFileWrites": true
  }
}

Auto 模式下最危险的事情不是 Claude 执行了什么，而是你不知道它执行了什么。开启审计日志后，每一次文件修改和命令执行都会被记录。每天花 2 分钟扫一眼日志，比事后排查问题快 100 倍。

不同场景的推荐配置

场景	推荐模式	关键设置
个人 side project	Auto + 宽松 allow	允许大多数操作，仅 deny push 和 rm
公司项目（有 CI）	Auto + 严格 deny	锁死 config/env/CI 文件，仅 allow src/
多人协作仓库	Plan 模式	让 Claude 先出方案再执行，避免冲突
生产环境相关	Manual	别用 Auto，逐条确认
开源项目维护	Auto + deny push	防止意外 push 到公开仓库

为什么不直接关掉 Auto 模式

可能有人会说：既然有风险，为什么不直接改回 Manual？

因为 Anthropic 的数据是对的——97% 的确认提示你都是无脑点的。Manual 模式给你的不是安全感，是"安全感的幻觉"。你觉得自己在审核，实际上第 10 次之后你就不看了。

Auto 模式 + 精确的 deny 规则，实际上比 Manual 模式更安全：

Manual：所有操作都问你 → 你疲劳后全部无脑批准 → 危险操作也被批准
Auto+deny：安全操作自动执行 → 你配置的 deny 规则硬性拦截 → 真正危险的操作必须手动确认

区别在于：Manual 模式的安全取决于你的注意力（会疲劳），Auto+deny 的安全取决于你的配置（不会疲劳）。

8/14 之前的检查清单

后天 Auto 模式就默认开启了。如果你还没配置过，至少做这几件事：

# 1. 检查当前的权限模式
cat .claude/settings.json

# 2. 如果文件不存在，创建一个
mkdir -p .claude
touch .claude/settings.json

# 3. 至少加上这个最小化安全配置
cat > .claude/settings.json << 'EOF'
{
  "permissions": {
    "deny": [
      "Write(.env*)",
      "Bash(git push*)",
      "Bash(git reset --hard*)",
      "Bash(rm -rf*)"
    ]
  }
}
EOF

# 4. 确认CLAUDE.md存在且有安全规则
cat CLAUDE.md

Auto 模式安全设置速查表

保护目标	deny 规则	优先级
环境变量/密钥	`Write(.env)`, `Read(.env)`	🔴 必须
不可逆 git 操作	`Bash(git push)`, `Bash(git reset --hard)`	🔴 必须
文件删除	`Bash(rm -rf)`, `Bash(rm -r )`	🔴 必须
CI/CD 配置	`Write(.github/**)`, `Write(.gitlab-ci.yml)`	🟡 强烈建议
包管理配置	`Write(package.json)`	🟡 视情况
全局安装	`Bash(npm install --global)`, `Bash(npx *)`	🟡 强烈建议
构建配置	`Write(webpack.config)`, `Write(vite.config)`	🟢 可选

核心原则：让 AI 自动做安全的事，硬性拦截危险的事

Auto 模式不是洪水猛兽。Anthropic 的数据证明了一个尴尬的事实：大多数人的"人工审核"其实比 AI 分类器更不靠谱。

但 11% 的漏网率也是真实的。后天开始，如果你什么都不配置，Claude Code 就会用它自己的判断来决定哪些操作安全——而它的判断有 11% 的概率是错的。

所以正确的策略不是二选一（全手动 vs 全自动），而是：让 Auto 处理 97% 的安全操作，用 deny 规则硬性拦截那 3% 你绝对不允许自动执行的东西。

你的 Claude Code 配置好了吗？8 月 14 日后天就到了。

我用 Claude Code 两天干完了团队两周的排期——周报发出去那一刻我就后悔了

193577746 — Tue, 11 Aug 2026 19:42:41 +0800

上周组里排了个技术债务清理的活，涉及三个模块的接口层重构，原本排期两周、三个人分着干。因为其中一个同事休假，另一个被临时抽去支援别的项目，最后这活落到了我头上。

我想着反正也得加班，不如试试全程用 Claude Code 推。结果两天半，三个模块全部重构完毕，自测通过，PR 提了。

周五写周报的时候，我在"本周完成"那栏写了一行："完成 XX 模块、YY 模块、ZZ 模块接口层重构（原排期两周）"。发出去之后 5 分钟，我就意识到不对了。

我为什么后悔

不是因为代码有问题。代码质量没问题，测试全过，Review 也通过了。

后悔的是：我把"效率差距"公开暴露了。

周报是全组可见的。当你一个人两天干完了原本三个人两周的活，本质上你在告诉所有人：要么这个排期本来就是虚的，要么其他人效率有问题。不管实际原因是什么（AI 工具、方案设计更合理、技术栈熟悉度），呈现出来的效果就是——你一个人让其他人的存在显得多余了。

周一开周会的时候，没人直接说什么，但我注意到了两件事：

老板问"接口层重构这块既然完成了，YY 模块后续的维护谁来接？"——潜台词是既然你做得快，后面的活也是你的
我之后提的一个需要两天的排期，被回了一句"你不是很快吗"

那一刻我才意识到：AI 让你变快了，但团队不是按"你最快"来运转的。

MIT 十万人研究证实的事：AI 让产出差 17 倍

这不是我一个人的体验。MIT 最近发了一份十万开发者规模的研究报告，核心结论是：使用 AI 编程工具后，个人代码产出量可以达到传统方式的 17 倍。

17 倍是什么概念？你一天的产出等于别人两周半。或者说，三个人的活你一个人两天半就干完了——对，就是我上周的真实场景。

但研究里还有一句很多人忽略的话："AI 压缩了实现功能的编码时间，但架构设计、跨团队沟通、复杂调试这些串行环节依然是瓶颈。更关键的是，AI 生成的代码反而加重了 Code Review 的负担。"

翻译成人话就是：你写得快了，但 review 你代码的人要花更多时间——而他们的效率并没有被 AI 提升。

5 个"AI 效率差距"制造的团队暗雷

我后来复盘了这件事，发现不止是"周报写得太快被挤兑"这么简单。AI 创造的效率差距，在团队里至少埋了 5 颗雷：

暗雷 1：你的效率高 = 别人效率低的放大镜

以前大家都在一个节奏上干活，快慢差距最多 2 倍。现在 AI 让这个差距拉到 5-17 倍。问题是：团队排期是按平均效率来的，不是按最快的人来的。

当你用 Claude Code 两天做完两周的活，你没有意识到的副作用是——团队的"正常速度基准"被你拉高了。下次排期的时候，所有人的 deadline 都会被参照你的速度压缩。

// 你以为你在做的事：
const myTask = await claudeCode.implement(moduleRefactor);
// 两天完成，提交PR

// 实际发生的事：
const teamBaseline = updateExpectation({
  before: '3人2周',
  after: '1人2天',
  implication: '以后所有类似任务的排期都按2天算'
});

暗雷 2：代码产出 ≠ 团队贡献

这是最反直觉的一点。你觉得"我两天做完了两周的活，贡献是 3 倍"，但团队视角完全不一样：

你以为的贡献	团队实际感受
产出量高=能力强	产出量高=AI 强，不是你强
快速完成=帮团队赶进度	快速完成=暴露排期有水分
一个人搞定=团队可以少投入人力	一个人搞定=其他人的价值被质疑
PR 质量高=值得信任	PR 量太大=没人有时间 review

当 AI 让"写代码"这个环节的边际成本趋近于零，团队的价值度量体系就崩了。 以前衡量一个人的标准是"你能产出多少高质量代码"，现在这个标准在被 AI 侵蚀——因为谁都能用 Claude Code 一句话生成整个模块。

暗雷 3：Review 负担转嫁

Thoughtworks 最新的软件工程报告里有一句话："AI 代码生成能力已经过剩，真正卡住行业脖子的是验证、信任和治理。"

翻译到团队日常就是：

// 你的工作流（2天）
const modules = ['auth', 'payment', 'notification'];
for (const mod of modules) {
  await claudeCode.refactor(mod); // 每个模块30分钟
  await runTests(mod); // 自动化测试10分钟
  await createPR(mod); // 提PR
}
// 总耗时：约6小时实际工作

// reviewer的工作流（???天）
for (const pr of threeModulePRs) {
  await readEveryLine(pr); // 每个PR 200-500行改动
  await understandContext(pr); // 为什么这样改？
  await verifyEdgeCases(pr); // AI有没有漏掉边界情况？
  await checkBackwardCompat(pr); // 向后兼容？
}
// 总耗时：至少2-3天集中review

你 2 天写完的代码，reviewer 可能需要 2-3 天才能 review 完。 而且 reviewer 不是用 AI review 的——他们需要逐行理解你的 AI 代码，验证每个改动的合理性。你用 AI 省下的时间，本质上是转嫁到了 reviewer 身上。

暗雷 4：排期博弈彻底失灵

软件工程有个潜规则：排期要留 buffer。一周的活排两周，给自己留空间处理意外、做技术调研、喘口气。

但当你用 AI 两天做完两周的活，你把这层 buffer 彻底撕碎了。后果：

你自己的 buffer 没了——下次类似的活，老板直接按"2 天"给你排
别人的 buffer 也没了——"他两天就行，你为什么要两周？"
整个团队的节奏被打乱——加班文化反而加重了，因为"AI 这么快你还要这么久？"

这就是我后悔的核心原因：我以为我在帮团队提效，实际上我在帮公司压缩整个团队的排期空间。

暗雷 5："用 AI 的人"和"不用 AI 的人"的隐形分裂

不是每个人都愿意或能够用 AI 编程。原因很多：

有人的项目涉及内网代码，安全合规不允许
有人习惯了自己的工作流，转换成本高
有人试过但效果不好（AI 对他们的技术栈支持差）
有人觉得"用 AI 写的代码我不放心"

当团队里一半人用 AI 产出 17 倍，另一半人维持原来的节奏，就形成了一个隐形的"两速团队"：

	用 AI 的人	不用 AI 的人
产出	高（但可能质量参差）	正常（但稳定）
Review	需要别人花更多时间 review	被迫花更多时间 review 别人的 AI 代码
排期	经常提前完成	被参照对比"为什么你要这么久"
团队感受	"我效率高"的优越感	"被 AI 时代淘汰"的焦虑感

这种分裂不会在周会上被讨论，但它每天都在侵蚀团队信任。

我后来怎么做的

踩完这个坑之后，我调整了几个习惯：

1. 不在周报里强调"速度"

以前写"两天完成三模块重构"，现在写"完成接口层重构，包含 XX 项优化"。不提时间，只提范围和质量。

2. AI 省下的时间用来做"不可见"的工作

提前完成之后，不急着汇报。用剩下的时间做文档补充、测试 case 补全、技术方案 review——这些不会出现在周报的"本周完成"里，但会在后续维护时救所有人的命。

3. 帮 reviewer 减负

大 PR 拆成小 PR，每个 PR 附上"改动原因"和"需要重点 review 的部分"的说明。AI 生成了 500 行代码，我在 PR 描述里写清楚"核心变更在第 30-50 行，其余是接口适配"。

4. 排期按"团队节奏"报，不按"我的 AI 速度"报

两天能做完的活，报一周。多出来的时间做上面说的不可见工作、帮别人 review、或者预研下一阶段的技术方案。不要把 AI 的能力当成你的能力去承诺。

AI 时代团队生存速查表

场景	错误做法	正确做法
周报	"两天完成两周排期"	"完成 XX 重构，含 N 项优化"
排期评估	按 AI 速度报真实时间	按团队节奏报，留 buffer
PR 提交	一次性提 500 行大 PR	拆成多个小 PR+ 详细描述
完成任务后	立刻汇报"搞定了"	用多余时间补文档/测试/review
被问"为什么这么快"	"用了 AI 工具"	"花了时间做方案设计 + 技术选型"
同事排期比你长	"他效率不行"	"他的场景可能更复杂"

核心原则：AI 让你变快了，但别让团队知道你有多快

这句话听起来很政治，但它是 AI 时代的团队生存法则。

AI 编程工具确实让个人效率暴增——MIT 数据说 17 倍，我体感也是这个量级。但团队不是一个人的竞速赛，它是一群人的协作系统。当你的速度远超系统的其他节点，你不是在帮系统提速，你是在让系统里的其他节点显得冗余。

真正聪明的做法不是"用 AI 卷死全组"，而是：把 AI 省下的时间投入到那些不能被 AI 替代的工作里——沟通、review、方案设计、帮助别人。 这些东西不会让你在周报上发光，但会让你在团队里长期安全。

你有没有也遇到过"用 AI 做得太快反而被挤兑"的情况？评论区聊聊你的版本。

# 面试官问"这段逻辑为什么这样写"——我才发现，这半年我写的代码，我自己都解释不了

193577746 — Mon, 10 Aug 2026 20:56:20 +0800

前两天面了一家公司，前两轮聊得还行，项目经历、技术选型、团队协作都答得上来。第三轮是技术深挖，面试官打开了我简历里提到的一个项目，屏幕共享让我打开某个组件的代码。

他指着一段逻辑问我："这里为什么用 useCallback 包了一层？"

我看了一眼那段代码——确实是我项目里的，但那一瞬间我脑子完全空白。因为那个组件是我用 Claude Code 生成的，当时 prompt 写的是"写一个带搜索功能的面板组件"，它给我生成了整个文件，我看了一眼能跑就提交了，从来没想过为什么要用 useCallback。

那次面试之后我做了一件事：把最近半年写的核心代码翻了一遍，对每段逻辑问自己"为什么这样写"。结果让我出了一身冷汗。

第一个说不出来的问题："这个 useCallback 是必要的吗？"

面试官问的原始代码大概长这样：

function SearchPanel({ onSearch }) {
  const [keyword, setKeyword] = useState('');

  const handleChange = useCallback((e) => {
    setKeyword(e.target.value);
  }, []);

  const handleSubmit = useCallback(() => {
    onSearch(keyword);
  }, [keyword, onSearch]);

  return (
    <div>
      <input value={keyword} onChange={handleChange} />
      <button onClick={handleSubmit}>搜索</button>
    </div>
  );
}

面试官追问："handleChange 这里用 useCallback，收益是什么？"

我当时的回答是："防止子组件不必要的重新渲染。"

面试官又问："input 是原生 DOM 元素，不是 React.memo 包裹的子组件——原生元素会因为父组件传入的 onChange 引用变化而重新渲染吗？"

我愣住了。

答案是不会。 原生 DOM 元素（<input>、<div>、<button>）不参与 React 的引用比较优化，它们每次父组件渲染时都会重新执行，不管你传入的 props 引用有没有变。useCallback 在这里完全没有意义——既不能减少渲染次数，还多了一层闭包和依赖数组维护的心智成本。

// ✅ 原生元素接收的回调，不需要useCallback
function SearchPanel({ onSearch }) {
  const [keyword, setKeyword] = useState('');

  const handleChange = (e) => {
    setKeyword(e.target.value);
  };

  const handleSubmit = () => {
    onSearch(keyword);
  };

  return (
    <div>
      <input value={keyword} onChange={handleChange} />
      <button onClick={handleSubmit}>搜索</button>
    </div>
  );
}

useCallback 只在一个场景下有意义：传给用 React.memo 包裹的子组件，或者作为 useEffect/useMemo 的依赖时需要引用稳定。传给原生元素纯属浪费。

这个错误我犯了多少次？翻了一下项目，至少 12 处。每一处都是 AI 生成整个组件时自动带上的，我从来没质疑过。

第二个说不出来的问题："并发请求怎么处理？"

面试进入第二个代码片段，是一个搜索联想组件：

function AutoComplete({ fetchSuggestions }) {
  const [query, setQuery] = useState('');
  const [suggestions, setSuggestions] = useState([]);

  useEffect(() => {
    if (query.length > 0) {
      fetchSuggestions(query).then((data) => {
        setSuggestions(data);
      });
    } else {
      setSuggestions([]);
    }
  }, [query]);

  return (
    <div>
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
      <ul>
        {suggestions.map((s) => <li key={s.id}>{s.text}</li>)}
      </ul>
    </div>
  );
}

面试官："如果用户快速输入'react'五个字母，'r'的请求比'react'的请求晚回来，会发生什么？"

我想了几秒才反应过来——显示的是'r'的搜索结果，而不是'react'的。竞态条件（Race Condition）。

面试官接着问："你项目里这个场景是怎么处理的？"

我诚实地说我不确定。因为这段代码也是 AI 一次性生成的整个组件，"能跑"之后我就没再深想。

正确的处理方式是用 AbortController 或者忽略过期请求：

function AutoComplete({ fetchSuggestions }) {
  const [query, setQuery] = useState('');
  const [suggestions, setSuggestions] = useState([]);

  useEffect(() => {
    if (query.length === 0) {
      setSuggestions([]);
      return;
    }

    const controller = new AbortController();

    fetchSuggestions(query, { signal: controller.signal })
      .then((data) => {
        setSuggestions(data);
      })
      .catch((err) => {
        if (err.name !== 'AbortError') throw err;
      });

    return () => controller.abort();
  }, [query]);

  return (
    <div>
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
      <ul>
        {suggestions.map((s) => <li key={s.id}>{s.text}</li>)}
      </ul>
    </div>
  );
}

或者用一个更轻量的方案——通过请求 ID 过滤过期响应：

useEffect(() => {
  if (query.length === 0) {
    setSuggestions([]);
    return;
  }

  let cancelled = false;

  fetchSuggestions(query).then((data) => {
    if (!cancelled) {
      setSuggestions(data);
    }
  });

  return () => { cancelled = true; };
}, [query]);

cleanup 函数里把cancelled设为true，下一次 effect 执行时，上一次的请求回来了也不会更新 state。

这个问题的要害在于：AI 生成的代码默认跑的是 happy path。 它给你一个"能工作"的版本，但不会主动替你想"如果网络慢/请求乱序/用户操作快会怎样"。而你用了半年 AI，习惯了"生成→能跑→提交"的流程，渐渐不再问自己"edge case 怎么办"。

第三个说不出来的问题："为什么拆成三个组件？"

面试官打开了我项目里一个表单页面，结构大概是这样：

// FormPage.tsx
function FormPage() {
  return (
    <FormContainer>
      <FormHeader />
      <FormBody />
      <FormFooter />
    </FormContainer>
  );
}

// FormHeader.tsx — 只有标题和一行描述
function FormHeader() {
  return (
    <div>
      <h2>创建项目</h2>
      <p>填写以下信息创建新项目</p>
    </div>
  );
}

面试官："FormHeader 只有两行静态文本，为什么要单独抽成组件？"

我又愣住了。

诚实的答案是：当时我在 Claude Code 里说"生成一个创建项目的表单页面"，它自动按 Header/Body/Footer 拆分的，我觉得"看起来很整洁"就接受了。但如果真要回答"为什么"——这里没有任何合理理由。

一个组件值得被拆出去的标准：

需要复用——其他地方也用同样的结构
有自己的状态或逻辑——内部管理着独立的 state 或 effect
是性能隔离边界——用 React.memo 包裹防止父组件渲染波及

FormHeader 一个都不满足。它既不复用，也没有状态，更不需要性能隔离。拆出去唯一的效果是多了一个文件、多了一次 import、多了一层组件调用栈——纯粹增加了项目的复杂度。

// ✅ 静态内容直接内联，不需要单独组件
function FormPage() {
  return (
    <FormContainer>
      <div>
        <h2>创建项目</h2>
        <p>填写以下信息创建新项目</p>
      </div>
      <FormBody />
      <FormFooter />
    </FormContainer>
  );
}

这不是一个"对错"的问题——很多人会说"拆了也没坏处"。但面试官真正在问的是：你做这个决策时有没有思考过。如果你的回答是"AI 这样生成的我就用了"，等于告诉面试官：你不做设计决策，你只是 AI 的提交工具。

为什么 AI 用久了会出现这种状态

面试完回去我复盘了很久，问题的本质不是"我的技术退步了"，而是AI 改变了我的工作方式。现在用 Claude Code 或者 Codex，一句话描述需求就能生成整个组件甚至整个页面，效率确实高了十倍——但代价是：

以前的工作流	现在的工作流
想清楚要写什么 → 一行行敲代码	一句 prompt 让 AI 生成整个组件 → 能跑 → 提交
遇到问题先想原因	遇到问题直接丢给 AI 重写
每行代码都是自己的决策	整个文件都是 AI 生成的，我只 review 了一遍
Code Review 时能解释每个选择	Code Review 时对 AI 生成的代码根本说不清"为什么"

关键区别：以前是"先思考后编码"，现在是"描述需求→AI 全盘实现→我看一眼→提交"。

AI 不会替你思考"为什么"。它给你"what"——一个能跑的完整实现。但面试官问的永远是"why"——为什么这样做而不是那样做。如果你只有 what 没有 why，在面试里就是裸奔。

面试前自检：你的代码你能解释吗？

面试后我给自己列了一个清单，翻项目代码时逐条对照：

5 个信号判断你是不是"AI 代理人"而不是"代码作者"：

打开三个月前写的组件，能在 30 秒内说出"为什么用这个 Hook 而不是另一个"吗？ 说不出来=你没做过这个决策
项目里有多少个 useCallback/useMemo？去掉它们会有可测量的性能差别吗？ 回答"不确定"=大概率是 AI 生成时惯性添加的
搜索项目里所有的 useEffect，每一个的 cleanup 函数你都知道为什么要那样写吗？ 不知道=你没思考过生命周期边界
随机打开一个你"写"的工具函数，能不看代码画出它的执行流程吗？ 画不出来=那是 AI 写的，你只是点了 accept
把你最近一次 PR 里的代码打印出来，不看电脑，能对着纸回答同事的追问吗？ 不能=这段代码你只"拥有"但不"理解"

如果 5 个里面命中 3 个以上，说明你现在的状态是：你负责写 prompt 描述需求，AI 负责整个实现。 面试官只要追问两次"为什么"，你就露馅。

面试前 3 天 AI 代码自审清单

审查维度	问自己的问题	常见 AI 盲区
性能决策	每个 useMemo/useCallback 都有必要吗？	生成整个组件时惯性给所有函数包 useCallback
边界处理	请求失败/超时/并发冲突怎么办？	只实现 happy path，不主动处理 edge case
组件边界	为什么这样拆分？有更简单的方式吗？	按"最佳实践模板"过度抽象
类型设计	TS 类型为什么这样定义？能收窄吗？	大量 any 或过于宽泛的联合类型
状态管理	这个 state 为什么放这层？有没有可以提升/下沉的？	默认把 state 全塞在同一个组件里
依赖关系	useEffect 的依赖数组每一项你都知道为什么需要吗？	按 eslint 提示全加，不思考必要性

核心原则：面试前把简历项目里 AI 写的代码全过一遍，对每段逻辑能回答"为什么这样做"和"如果不这样做会怎样"。 不是让你重写，是让你理解。

不是不用 AI，是用了之后多问一个"为什么"

这次面试给我最大的教训不是"AI 不好"，而是：我把 AI 当成了可以全权委托的外包，但它其实只是一个不解释理由的代码生成器。

同事帮你写一段代码，你会问"为什么这样写"；AI 帮你生成整个组件，你看一眼能跑就 merge 了。这个差距在日常工作里看不出来——代码能跑，Review 能过，线上不出事。但面试官专门戳的就是这个缝隙：你到底是代码的作者，还是 AI 的提交工具？

以后我用 AI 的习惯会加一步：每次 AI 生成完代码，花 5 分钟逐段问自己"如果面试官问我为什么，我怎么回答"。答不上来的——要么搞懂再提交，要么让 AI 解释清楚再接受。

你有没有也遇到过面试官追问"为什么"的时候答不上来的瞬间？评论区聊聊你的版本。

我踩了三次同一个坑才明白：React 里"改了数据却不重新渲染"的真正原因

193577746 — Sun, 09 Aug 2026 20:50:13 +0800

"我明明改了 state，页面怎么没反应？"这句话我至少在三个不同的项目里对自己说过。三次踩坑的代码看起来完全不一样，但 debug 到最后，罪魁祸首是同一个东西：我以为自己改了数据，但只是改了数据的内容，没有改数据的引用。

第一次：数组 push 之后不重新渲染

// ❌ push改变了数组内容，但引用没变
function TodoList() {
  const [todos, setTodos] = useState([]);

  const addTodo = (text) => {
    todos.push({ id: Date.now(), text }); // 直接mutate原数组
    setTodos(todos); // 传进去的还是同一个引用！
  };

  return (
    <div>
      {todos.map((t) => <div key={t.id}>{t.text}</div>)}
      <button onClick={() => addTodo('新任务')}>添加</button>
    </div>
  );
}

点击按钮，控制台打印todos确实多了一条数据，但页面死活不刷新。这是我第一次遇到这个问题时最懵的地方——数据明明变了，为什么不渲染？

第二次：嵌套对象属性修改后不生效

// ❌ 直接改嵌套属性，外层引用没变
function UserProfile() {
  const [user, setUser] = useState({ name: '张三', settings: { theme: 'light' } });

  const toggleTheme = () => {
    user.settings.theme = user.settings.theme === 'light' ? 'dark' : 'light';
    setUser(user); // 还是同一个user对象
  };

  return (
    <div>
      <p>当前主题：{user.settings.theme}</p>
      <button onClick={toggleTheme}>切换主题</button>
    </div>
  );
}

这次更隐蔽，因为改的是嵌套两层的属性——很容易让人觉得"我确实改了一个具体的值，应该生效"。但结果和第一次一样：点了按钮，UI 毫无反应。

第三次：useMemo 依赖数组失效

// ❌ 依赖的对象被mutate，useMemo认为"没变"
function FilterPanel({ initialFilters }) {
  const [filters, setFilters] = useState(initialFilters);

  const activeCount = useMemo(() => {
    return Object.values(filters).filter(Boolean).length;
  }, [filters]);

  const toggleFilter = (key) => {
    filters[key] = !filters[key]; // 直接mutate
    setFilters(filters); // 引用没变
  };

  return (
    <div>
      <p>已选：{activeCount}项</p>
      {/* activeCount永远显示初始值，因为useMemo的依赖比较发现filters引用没变，直接返回缓存值 */}
    </div>
  );
}

这次最难排查，因为 bug 表现是"某个计算值一直不更新"，而不是"整个组件不渲染"——第一反应根本不会往"引用没变"这个方向想。

三次坑的共同原因：React 用浅比较判断"变没变"

React（以及useMemo、useCallback、React.memo）判断一个值是否变化，用的是Object.is（本质上是===浅比较），不会递归比较对象内部的每一个字段。

const a = { count: 1 };
const b = a;
b.count = 2;

console.log(a === b); // true！引用完全相同
console.log(a.count); // 2，值确实变了

当你直接修改对象/数组的属性（mutate），JS 引擎里这仍然是"同一个对象"，只是它内部的字段变了。但Object.is(oldState, newState)比较的是引用地址，不是内容——所以 React（或useMemo）看到的结论永远是"没变"，直接跳过重新渲染或跳过重新计算。

这也解释了为什么直接console.log能看到最新值——你打印的是同一个对象，它的内容确实更新了。但 React 根本不关心内容，只关心"这还是不是同一个引用"。

统一的修复方式：永远创建新引用

// ✅ 数组：用展开运算符创建新数组
const addTodo = (text) => {
  setTodos([...todos, { id: Date.now(), text }]);
};

// ✅ 嵌套对象：逐层展开
const toggleTheme = () => {
  setUser({
    ...user,
    settings: {
      ...user.settings,
      theme: user.settings.theme === 'light' ? 'dark' : 'light',
    },
  });
};

// ✅ useMemo依赖的对象同理，更新时创建新对象
const toggleFilter = (key) => {
  setFilters({ ...filters, [key]: !filters[key] });
};

原则：更新 state 永远不要直接修改原对象/数组的属性，永远返回一个新的引用。[...arr]、{...obj}、arr.map()、arr.filter()都是安全的，因为它们都会生成新的容器。

数组常用操作的安全/危险对照表

操作	是否 mutate 原数组	安全用法
`push` / `pop` / `shift` / `unshift`	✅ 会 mutate	用`[...arr, item]` / `arr.slice(1)`
`splice`	✅ 会 mutate	用`arr.filter()`或展开 +slice 组合
`sort` / `reverse`	✅ 会 mutate	先`[...arr]`拷贝一份再排序
`map` / `filter` / `slice`	❌ 不 mutate，安全	直接用
`concat`	❌ 不 mutate，安全	直接用

sort和reverse是最容易被忽略的两个——很多人以为它们"只是排序展示，应该没事"，但它们会直接修改原数组，只是刚好排序后位置变了，如果你恰好没有依赖引用比较，表面上看不出问题，但一旦配合useMemo或React.memo就会诡异地失效。

为什么这个坑会反复踩

因为 mutate 的代码"看起来是对的"——todos.push(item)完全符合直觉，user.settings.theme = 'dark'也是最朴素的赋值写法。JS 语言本身完全允许你这样写，不会有任何警告或报错。

真正的坑在于：React 的渲染机制建立在"引用比较"这个假设上，但 JS 语言本身的默写习惯是"直接改内容"。这两者的错位就是 bug 的根源，而且因为不报错，只在 UI 层表现为"数据变了但没重新渲染"，很容易让人怀疑是不是 state 更新的时机问题、要不要加forceUpdate、要不要检查依赖数组——反而不会想到"我是不是 mutate 了"。

排查这类问题的最快方法

如果你遇到"改了数据 UI 不更新"的情况，先做这个测试：

const before = state;
// 执行你的更新逻辑
const after = state; // 或者拿到你以为的"新state"
console.log(before === after); // 如果是true，说明你在mutate

如果这行打印true，不用继续排查别的可能性了，直接去检查更新逻辑是不是在 mutate 原数据。

你有没有也在"改了但不渲染"这个坑里反复摔过？

觉得有用？点个「赞」👍 让更多人看到

关注我，获取更多技术干货。

我排查了一个 React 内存泄漏——罪魁祸首是这 3 个被忽略的清理函数

193577746 — Fri, 07 Aug 2026 19:03:33 +0800

页面开久了会越来越卡，任务管理器里内存曲线一路向上不回头。这种问题很难在开发阶段发现——本地刷新几次根本看不出来，非要挂在后台跑上几十分钟才会暴露。

我用 Chrome DevTools 的 Memory 面板做了几轮 heap snapshot 对比，最后揪出 3 个罪魁祸首，全部是同一个模式：注册了监听，但没有对应的清理函数。

怎么发现的：heap snapshot 对比

打开 DevTools → Memory → 选 Heap snapshot，在页面正常操作几轮后拍一张，触发几次导致怀疑的操作（比如打开关闭一个弹窗、切换几次 tab）后再拍一张，用 Comparison 视图看两次 snapshot 之间 New（新增未释放）的对象。

如果同一类对象（比如Detached HTMLDivElement、某个自定义类的实例）持续增长且不回落，基本可以确定是内存泄漏。我这次看到的是(closure)和Detached节点数量随着"打开弹窗→关闭弹窗"的操作次数线性增长——每次关闭理论上应该清零，但没有。

罪魁祸首 1：window 上的事件监听没有移除

// ❌ 加了监听，忘了摘
function ResizablePanel() {
  const [width, setWidth] = useState(300);

  useEffect(() => {
    const handleResize = () => {
      setWidth(window.innerWidth * 0.3);
    };
    window.addEventListener('resize', handleResize);
    // 没有return清理函数！
  }, []);

  return <div style={{ width }}>面板内容</div>;
}

这个组件卸载后，handleResize这个函数依然被window持有引用。而这个函数的闭包里又引用了setWidth——间接引用了组件实例。只要window还活着（它当然一直活着），这个函数、这个闭包、间接关联的组件相关对象，全部无法被垃圾回收。

如果这个组件会被频繁挂载/卸载（比如一个可以打开关闭的侧边栏面板），每次挂载都新增一个resize监听，卸载时不清理——泄漏会随着用户操作次数线性累积。

// ✅ useEffect返回清理函数
function ResizablePanel() {
  const [width, setWidth] = useState(300);

  useEffect(() => {
    const handleResize = () => {
      setWidth(window.innerWidth * 0.3);
    };
    window.addEventListener('resize', handleResize);

    return () => {
      window.removeEventListener('resize', handleResize);
    };
  }, []);

  return <div style={{ width }}>面板内容</div>;
}

原则：任何addEventListener都必须有对应的removeEventListener，写在useEffect的清理函数里。这条规则没有例外。

罪魁祸首 2：WebSocket/订阅类连接没有关闭

// ❌ 建立连接，没有断开
function LiveChart({ symbol }) {
  const [price, setPrice] = useState(0);

  useEffect(() => {
    const ws = new WebSocket(`wss://api.example.com/ticker/${symbol}`);
    ws.onmessage = (event) => {
      setPrice(JSON.parse(event.data).price);
    };
    // ws没有在任何地方close！
  }, [symbol]);

  return <div>{symbol}: {price}</div>;
}

这个问题比普通事件监听更隐蔽，也更严重。symbol每变化一次，useEffect重新执行一次，就创建一个新的WebSocket连接——旧的连接因为没有close()，永远不会断开。

用户在不同股票/币种之间切换 10 次，本地就有 10 个活跃的 WebSocket 连接同时在后台跑，持续接收数据、持续触发onmessage回调、持续调用已经"该死但没死"的组件相关闭包。这不只是内存泄漏，还是真实的网络资源浪费和不必要的服务器压力。

// ✅ 依赖变化或组件卸载时关闭连接
function LiveChart({ symbol }) {
  const [price, setPrice] = useState(0);

  useEffect(() => {
    const ws = new WebSocket(`wss://api.example.com/ticker/${symbol}`);
    ws.onmessage = (event) => {
      setPrice(JSON.parse(event.data).price);
    };

    return () => {
      ws.close();
    };
  }, [symbol]);

  return <div>{symbol}: {price}</div>;
}

同样的模式适用于EventSource（SSE）、第三方库返回的subscribe()函数（比如 RxJS 的 Observable、Firebase 的onSnapshot）——只要是"注册一个持续接收数据的通道"，就必须有"注销这个通道"的对应代码。

原则：WebSocket用close()，EventSource用close()，任何subscribe返回的unsubscribe函数必须调用。这类资源不会因为组件卸载而自动断开，JS 引擎不知道你的 React 组件生命周期。

罪魁祸首 3：第三方库实例没有调用 destroy/dispose

// ❌ 创建了图表实例，卸载时没有销毁
function SalesChart({ data }) {
  const chartRef = useRef(null);

  useEffect(() => {
    const chart = echarts.init(chartRef.current);
    chart.setOption({
      series: [{ type: 'line', data }],
    });
    // chart实例没有dispose！
  }, [data]);

  return <div ref={chartRef} style={{ height: 400 }} />;
}

这是我这次排查中泄漏量最大的一个。ECharts、Chart.js、地图库（Leaflet、AMap）这类可视化库，通常会在内部维护自己的 Canvas 上下文、事件系统、内部状态树——这些都是独立于 React 生命周期之外的对象。

组件卸载后，DOM 节点被 React 移除了，但echarts.init返回的这个chart实例依然存活在内存里，它内部持有的 Canvas、离屏渲染缓存、绑定在 DOM 节点上的事件监听全部不会自动释放。这类实例通常体积比普通 JS 对象大得多——一个图表实例可能就是几 MB，10 个页面来回切换，内存就能涨出几十 MB。

// ✅ 卸载时调用库提供的销毁方法
function SalesChart({ data }) {
  const chartRef = useRef(null);

  useEffect(() => {
    const chart = echarts.init(chartRef.current);
    chart.setOption({
      series: [{ type: 'line', data }],
    });

    return () => {
      chart.dispose();
    };
  }, [data]);

  return <div ref={chartRef} style={{ height: 400 }} />;
}

原则：任何"由第三方库的init/create方法返回的实例"，先去查文档有没有destroy/dispose/unmount方法。有就必须在清理函数里调用——这是库作者主动告诉你"这个实例需要手动释放"的信号。

排查思路总结

这 3 个罪魁祸首的共同模式其实只有一句话：任何"注册"操作，都要找到它对应的"注销"操作。

注册操作	对应的注销操作
`addEventListener`	`removeEventListener`
`new WebSocket()`	`.close()`
`new EventSource()`	`.close()`
`观察者.subscribe()`	调用返回的`unsubscribe`函数
`第三方库.init()`	查文档的`destroy`/`dispose`
`setTimeout`/`setInterval`	`clearTimeout`/`clearInterval`

排查内存泄漏最有效的方法不是死磕代码逐行看，而是：

打开 Memory 面板，操作前后各拍一次 heap snapshot
用 Comparison 视图找持续增长且不回落的对象类型
顺着对象类型反查是哪个组件在创建它
检查这个组件的useEffect里，创建操作是否配了对应的清理函数

内存泄漏不会让你的项目立刻崩溃

这也是为什么它比逻辑 bug 更容易被忽视——它不会让测试用例失败，不会在 Code Review 里显眼地报错，只会让线上跑得越久的页面越卡，直到某个用户反馈"打开一整天卡得不行"，你才会想起来查。

useEffect返回清理函数这个机制，React 团队从一开始就设计好了。真正的问题从来不是"不知道怎么清理"，而是写代码的时候没有意识到"这里需要清理"。

你的项目里，有没有一个useEffect创建了什么东西，却从来没写过对应的清理函数？

我重写了自己用了两年的防抖节流 Hook——发现里面藏着 3 个隐藏 bug

193577746 — Thu, 06 Aug 2026 19:27:42 +0800

防抖节流是前端最基础的知识点之一。随手从网上抄一个useDebounce、useThrottle塞进项目，能跑，两年没出过大问题。

直到最近排查一个诡异的内存泄漏警告，我把这个用了两年的 Hook 翻出来重新看了一遍——发现里面藏着 3 个隐藏 bug，平时根本不会触发，一旦触发就是线上事故。

我两年前写的版本

// 两年前的版本，能跑，但有问题
function useDebounce(callback, delay) {
  const timerRef = useRef(null);

  const debouncedFn = (...args) => {
    if (timerRef.current) {
      clearTimeout(timerRef.current);
    }
    timerRef.current = setTimeout(() => {
      callback(...args);
    }, delay);
  };

  return debouncedFn;
}

用法：

function SearchBox() {
  const [keyword, setKeyword] = useState('');

  const search = useDebounce((value) => {
    fetchSearchResults(value).then(setResults);
  }, 300);

  return <input onChange={(e) => search(e.target.value)} />;
}

这段代码在大部分场景下工作得很好。但它藏着 3 个问题。

隐藏 bug1：组件卸载后依然执行回调

function SearchBox() {
  const [keyword, setKeyword] = useState('');
  const [results, setResults] = useState([]);

  const search = useDebounce((value) => {
    fetchSearchResults(value).then((data) => {
      setResults(data); // 组件可能已经卸载了！
    });
  }, 300);

  return <input onChange={(e) => search(e.target.value)} />;
}

触发场景： 用户输入关键词后立刻跳转到别的页面。300ms 后，防抖的回调触发，setResults执行在一个已经卸载的组件上——React 会在控制台警告"Cannot update state on an unmounted component"，虽然不会直接崩溃，但如果这个回调里有其他副作用（比如写 localStorage、发埋点），可能真的会出问题。

// ✅ 组件卸载时清理定时器
function useDebounce(callback, delay) {
  const timerRef = useRef(null);

  useEffect(() => {
    return () => {
      if (timerRef.current) {
        clearTimeout(timerRef.current);
      }
    };
  }, []);

  const debouncedFn = (...args) => {
    if (timerRef.current) {
      clearTimeout(timerRef.current);
    }
    timerRef.current = setTimeout(() => {
      callback(...args);
    }, delay);
  };

  return debouncedFn;
}

原则：所有用setTimeout/setInterval的 Hook，必须在useEffect的清理函数里清掉定时器。这不是可选项，是必选项。

隐藏 bug2：闭包里的 callback 是旧的（stale closure）

这是最隐蔽的一个。先看一个复现场景：

function SearchBox() {
  const [keyword, setKeyword] = useState('');
  const [category, setCategory] = useState('all');

  // category变化时，search函数应该拿到最新的category
  const search = useDebounce((value) => {
    fetchSearchResults(value, category).then(setResults);
    // 这里的category永远是Hook第一次创建时的值！
  }, 300);

  return (
    <div>
      <select onChange={(e) => setCategory(e.target.value)}>
        <option value="all">全部</option>
        <option value="books">图书</option>
      </select>
      <input onChange={(e) => search(e.target.value)} />
    </div>
  );
}

为什么？ useDebounce只在组件首次渲染时创建了debouncedFn这个函数（如果没有依赖数组控制），这个函数内部闭包捕获的callback是第一次渲染时传进来的那个函数。之后即使category变了，组件重新渲染，callback里引用的还是旧的category。

这就是经典的stale closure（闭包过期）问题。用户明明切换了分类，但搜索请求带的还是旧分类——bug 非常隐蔽，因为大多数时候你测试时不会正好在防抖等待期间切换筹码。

// ✅ 用ref存最新的callback，避免闭包过期
function useDebounce(callback, delay) {
  const timerRef = useRef(null);
  const callbackRef = useRef(callback);

  // 每次渲染都更新ref，保证拿到的是最新的callback
  useEffect(() => {
    callbackRef.current = callback;
  }, [callback]);

  useEffect(() => {
    return () => {
      if (timerRef.current) clearTimeout(timerRef.current);
    };
  }, []);

  const debouncedFn = useCallback((...args) => {
    if (timerRef.current) clearTimeout(timerRef.current);
    timerRef.current = setTimeout(() => {
      callbackRef.current(...args); // 永远拿最新的callback
    }, delay);
  }, [delay]);

  return debouncedFn;
}

原则：Hook 内部如果要长期持有一个外部传入的函数，用ref存最新值，不要指望闭包会自动更新。

这也是为什么useEffect的依赖数组这么重要——它就是在提醒你"闭包会过期"这件事。

隐藏 bug3：没有取消方法，无法主动打断

function SearchBox() {
  const search = useDebounce((value) => {
    fetchSearchResults(value).then(setResults);
  }, 300);

  const handleClear = () => {
    setKeyword('');
    setResults([]);
    // 但是search之前排队的那次调用还会在300ms后执行！
    // 清空后0.3秒，搜索结果又跳出来了
  };

  return (
    <div>
      <input onChange={(e) => search(e.target.value)} />
      <button onClick={handleClear}>清空</button>
    </div>
  );
}

触发场景： 用户输入了关键词，防抖计时器在跑。这时用户点了"清空"按钮，UI 上结果确实清空了——但 0.3 秒后，之前排队的防抖回调触发，搜索结果又跳出来覆盖了清空状态。用户会看到一个诡异的"清空后又自己冒出内容"的 bug。

我们的useDebounce只提供了触发方法，没有提供取消方法。这是一个功能缺失，不是逻辑错误，但同样会导致真实的用户体验问题。

// ✅ 提供cancel方法，让外部可以主动打断
function useDebounce(callback, delay) {
  const timerRef = useRef(null);
  const callbackRef = useRef(callback);

  useEffect(() => {
    callbackRef.current = callback;
  }, [callback]);

  useEffect(() => {
    return () => {
      if (timerRef.current) clearTimeout(timerRef.current);
    };
  }, []);

  const debouncedFn = useCallback((...args) => {
    if (timerRef.current) clearTimeout(timerRef.current);
    timerRef.current = setTimeout(() => {
      callbackRef.current(...args);
    }, delay);
  }, [delay]);

  const cancel = useCallback(() => {
    if (timerRef.current) {
      clearTimeout(timerRef.current);
      timerRef.current = null;
    }
  }, []);

  return [debouncedFn, cancel];
}

// 用法：拿到cancel方法，在需要打断的地方调用
function SearchBox() {
  const [search, cancelSearch] = useDebounce((value) => {
    fetchSearchResults(value).then(setResults);
  }, 300);

  const handleClear = () => {
    setKeyword('');
    setResults([]);
    cancelSearch(); // 主动打断排队中的调用
  };

  return (
    <div>
      <input onChange={(e) => search(e.target.value)} />
      <button onClick={handleClear}>清空</button>
    </div>
  );
}

原则：任何"延迟执行"的机制，都要配一个"取消执行"的出口。没有取消方法的防抖/节流，只是半成品。

节流（throttle）也有一样的问题

把上面的思路套到节流上，同样的 3 个 bug 会以不同形式出现：

// ✅ 完整版useThrottle，同样处理3个问题
function useThrottle(callback, delay) {
  const timerRef = useRef(null);
  const lastRunRef = useRef(0);
  const callbackRef = useRef(callback);

  useEffect(() => {
    callbackRef.current = callback;
  }, [callback]);

  useEffect(() => {
    return () => {
      if (timerRef.current) clearTimeout(timerRef.current);
    };
  }, []);

  const throttledFn = useCallback((...args) => {
    const now = Date.now();
    const remaining = delay - (now - lastRunRef.current);

    if (remaining <= 0) {
      lastRunRef.current = now;
      callbackRef.current(...args);
    } else if (!timerRef.current) {
      timerRef.current = setTimeout(() => {
        lastRunRef.current = Date.now();
        timerRef.current = null;
        callbackRef.current(...args);
      }, remaining);
    }
  }, [delay]);

  const cancel = useCallback(() => {
    if (timerRef.current) {
      clearTimeout(timerRef.current);
      timerRef.current = null;
    }
  }, []);

  return [throttledFn, cancel];
}

节流比防抖多一个细节：要不要"leading"（第一次触发立即执行）和"trailing"（最后一次触发后再执行一次）。这两种语义在滚动监听和按钮防重复点击场景下完全不同，用之前一定要想清楚你要的是哪种。

速查表

隐藏 bug	触发场景	修复
卸载后仍执行	组件卸载时定时器还在跑	useEffect 清理函数里 clearTimeout
闭包过期	依赖的外部变量变化后不生效	用 ref 存最新 callback
无法取消	需要主动打断排队中的调用	暴露 cancel 方法

两年没出问题≠没有 bug

这 3 个 bug 之所以在生产环境潜伏了两年没被发现，是因为触发条件都比较刁钻：卸载时机的竞态、依赖变化的时序、需要主动打断的交互。日常测试很难覆盖到。

但只要项目跑得足够久、用户量足够大，这些边界情况迟早会被撞到。

工具函数这种"抄一遍就不再看"的代码，反而是最容易埋雷的地方——因为没人会因为"它一直没出问题"而主动去重新审视它。

你项目里的防抖节流 Hook，有取消方法吗？

觉得有用？点个「赞」👍 让更多人看到

关注我，获取更多技术干货。

别再这样写条件渲染了——你的 React 组件里藏着这 5 种定时炸弹

193577746 — Wed, 05 Aug 2026 19:34:53 +0800

你的 React 组件里一定有条件渲染。

{condition && <Component />}、三元表达式、if/else——这些你每天都在写。

但这些写法里有 5 种坑，不出问题的时候一切正常，一旦触发就是线上事故。我在生产环境里被炸了不止一次。

炸弹 1：&& 短路渲染出一个"0"

// ❌ 你以为它不会渲染，但它渲染了一个 "0"
function NotificationBadge({ count }) {
  return (
    <div>
      {count && <span className="badge">{count}</span>}
    </div>
  );
}

// 当 count = 0 时，页面上会出现一个孤零零的 "0"

为什么？ && 的短路规则：左侧是 falsy 就返回左侧的值。0 是 falsy，所以返回 0。React 会把数字 0 渲染到 DOM 里。

同样的坑还有 "" 空字符串——不会渲染，但 NaN 会渲染出 "NaN"。

// ✅ 显式转为布尔值
{count > 0 && <span className="badge">{count}</span>}

// 或者用三元
{count ? <span className="badge">{count}</span> : null}

// 通用安全写法：!!
{!!items.length && <List items={items} />}

原则：&& 左侧必须是布尔表达式，永远不要放数字或可能为 0 的变量。

炸弹 2：三元嵌套超过两层

// ❌ 三个月后你自己都看不懂
return (
  <div>
    {isLoading
      ? <Spinner />
      : error
        ? <ErrorMessage error={error} />
        : data
          ? data.items.length > 0
            ? <List items={data.items} />
            : <EmptyState />
          : null}
  </div>
);

这段代码现在能跑。但下周产品说"加载失败要有重试按钮"，你要在哪层加？哪层是 error 的分支？看 3 分钟才能确认。

// ✅ 早返回 + 分离
function DataView({ isLoading, error, data }) {
  if (isLoading) return <Spinner />;
  if (error) return <ErrorMessage error={error} />;
  if (!data || data.items.length === 0) return <EmptyState />;

  return <List items={data.items} />;
}

原则：三元表达式最多嵌套一层。超过一层就拆成 if 早返回或抽成子组件。

炸弹 3：条件渲染导致组件状态丢失

// ❌ 切换tab后表单输入全丢了
function TabPanel({ activeTab }) {
  return (
    <div>
      {activeTab === 'form' && <UserForm />}
      {activeTab === 'preview' && <Preview />}
    </div>
  );
}

用户在表单里填了一堆数据，切到 Preview 看看效果，切回来——表单空了。

因为 && 条件为 false 时组件被卸载了，所有内部 state 都丢了。

// ✅ 方案1：用 CSS 隐藏而不是卸载
function TabPanel({ activeTab }) {
  return (
    <div>
      <div style={{ display: activeTab === 'form' ? 'block' : 'none' }}>
        <UserForm />
      </div>
      <div style={{ display: activeTab === 'preview' ? 'block' : 'none' }}>
        <Preview />
      </div>
    </div>
  );
}

// ✅ 方案2：状态提升到父组件
function TabPanel({ activeTab }) {
  const [formData, setFormData] = useState({});

  return (
    <div>
      {activeTab === 'form' && (
        <UserForm data={formData} onChange={setFormData} />
      )}
      {activeTab === 'preview' && <Preview data={formData} />}
    </div>
  );
}

原则：条件渲染 = 卸载/重新挂载。如果组件有用户输入或内部状态，要么用 CSS 隐藏，要么把状态提升。

炸弹 4：用 useEffect + state 做"派生"条件

// ❌ 用useEffect同步计算一个本该直接派生的值
function ProductList({ products, category }) {
  const [filteredProducts, setFilteredProducts] = useState([]);

  useEffect(() => {
    setFilteredProducts(products.filter(p => p.category === category));
  }, [products, category]);

  return (
    <div>
      {filteredProducts.length > 0
        ? <List items={filteredProducts} />
        : <EmptyState />}
    </div>
  );
}

看着好像没问题。但这里有两个 bug：

首次渲染闪烁：组件先渲染一次空列表（useState([])），然后 useEffect 执行后触发第二次渲染。用户会看到 EmptyState 闪一下。
不必要的渲染：每次 products/category 变化会触发两次渲染——一次正常渲染、一次 useEffect 触发的 setState。

// ✅ 直接计算，不要"同步"
function ProductList({ products, category }) {
  const filteredProducts = products.filter(p => p.category === category);

  return (
    <div>
      {filteredProducts.length > 0
        ? <List items={filteredProducts} />
        : <EmptyState />}
    </div>
  );
}

没有 state，没有 effect，没有闪烁，没有多余渲染。 如果 filter 逻辑很重，用 useMemo——但别用 useEffect + setState。

原则：能从 props/state 直接算出来的值，就直接算。不要用 useEffect "同步"到另一个 state。

（这个也是我之前写过的 useEffect 反模式之一——但在条件渲染场景中特别容易犯。）

炸弹 5：key 相同导致条件切换时状态"串台"

// ❌ 两个输入框共享了同一个DOM，状态互相污染
function AuthForm({ mode }) {
  return (
    <div>
      {mode === 'login'
        ? <input placeholder="用户名" />
        : <input placeholder="邮箱" />}
    </div>
  );
}

用户在登录模式输入了用户名，切到注册模式——邮箱输入框里出现了刚才输入的用户名。

原因：React 的 reconciliation 认为这是同一个 <input> 节点（相同位置、相同类型），所以复用 DOM，不重置 state。

// ✅ 给不同分支加不同的 key，强制React重建
function AuthForm({ mode }) {
  return (
    <div>
      {mode === 'login'
        ? <input key="login" placeholder="用户名" />
        : <input key="register" placeholder="邮箱" />}
    </div>
  );
}

key 不同 → React 销毁旧节点、创建新节点 → state 不会串台。

// 复杂场景：整个表单组件切换
{mode === 'login'
  ? <LoginForm key="login" />
  : <RegisterForm key="register" />}

原则：当条件渲染的两个分支是"不同的东西"但 DOM 结构相似时，必须加不同的 key 防止状态串台。

速查表

定时炸弹	触发条件	修复
&& 渲染 "0"	左侧是数字/NaN	改用 `> 0` 或 `!!`
三元嵌套	超过 2 层	拆成 if 早返回
状态丢失	条件 false=卸载	CSS 隐藏或状态提升
派生条件用 effect	useEffect+setState	直接计算/useMemo
key 串台	同位置同类型 DOM	加不同 key

你踩过哪颗？

这 5 个里面，我在生产环境踩过 3 颗。第 1 颗（&&渲染 0）和第 5 颗（key 串台）是线上 bug 排查了半小时才定位到的——因为本地测试数据永远不为 0，永远不切换模式。

条件渲染看着简单，但它直接关系到 React 的渲染机制、reconciliation 算法、组件生命周期。写错了不会报错，只会在某个边界条件下默默炸给用户看。

你踩过哪颗炸弹？评论区说说。

别再这样写 TypeScript 了——Code Review 中最常见的 8 个反模式

193577746 — Tue, 04 Aug 2026 19:54:53 +0800

最近 Code Review 了组里三个新人的代码，发现同样的问题反复出现。

不是逻辑错误——TypeScript 编译器会帮你抓。是那种能跑，但让接手的人想打人的写法。

总结了 8 个最常见的反模式。你可能正在写其中至少 3 个。

反模式 1：any 当万能胶

// ❌ 遇到类型报错就any
const handleResponse = (data: any) => {
  return data.result.items.map((item: any) => item.name);
};

看着没问题。但 data 的结构变了呢？items 不存在了呢？name 改成 title 了呢？

TypeScript 不会告诉你——因为你告诉它"我不在乎类型"。

// ✅ 花30秒定义类型
interface ApiResponse {
  result: {
    items: Array<{ name: string; id: number }>;
  };
}

const handleResponse = (data: ApiResponse) => {
  return data.result.items.map((item) => item.name);
};

原则：每多一个 any，你的 TypeScript 就退化成了带类型注释的 JavaScript。

如果你真的不知道类型是什么——用 unknown，下一节说为什么。

反模式 2：try-catch 里用 any 而不是 unknown

// ❌ catch里用any
try {
  await fetchData();
} catch (error: any) {
  console.log(error.message);  // 如果error不是Error对象呢？
  console.log(error.response.status);  // 如果没有response呢？
}

catch 的 error 可能是任何东西——不只是 Error 对象。有可能是字符串、null、甚至 undefined。

// ✅ 用unknown + 类型守卫
try {
  await fetchData();
} catch (error: unknown) {
  if (error instanceof Error) {
    console.log(error.message);
  }
  if (isAxiosError(error)) {
    console.log(error.response?.status);
  }
}

unknown 强制你在使用前做类型检查——any 则让你假装知道它是什么。

反模式 3：as 断言代替类型守卫

// ❌ 到处用 as 强转
const user = response.data as User;
const element = document.getElementById('root') as HTMLDivElement;
const config = JSON.parse(text) as AppConfig;

as 的意思是"我比编译器更懂"。但你真的更懂吗？

如果 response.data 返回的不是 User 结构？如果那个 DOM 元素不存在或者不是 div？运行时崩溃，TypeScript 不会预警。

// ✅ 用类型守卫做运行时检查
function isUser(data: unknown): data is User {
  return (
    typeof data === 'object' &&
    data !== null &&
    'id' in data &&
    'name' in data
  );
}

const data = response.data;
if (isUser(data)) {
  // 这里 data 被收窄为 User，编译器和运行时都安全
  console.log(data.name);
}

// DOM 元素用 instanceof
const element = document.getElementById('root');
if (element instanceof HTMLDivElement) {
  element.style.display = 'flex';
}

原则：as 是骗编译器，类型守卫是让编译器帮你验证。

唯一合理用 as 的场景：你能 100% 确定类型，且加守卫的成本不值得（比如测试代码里 mock 数据）。

反模式 4：枚举滥用（该用 union type 的场景）

// ❌ 为了几个固定值搞个enum
enum Status {
  Active = 'active',
  Inactive = 'inactive',
  Pending = 'pending',
}

enum Direction {
  Up = 'up',
  Down = 'down',
  Left = 'left',
  Right = 'right',
}

enum 看着很规范，但它有两个问题：

编译后会生成额外的运行时代码（一个 IIFE 对象）
数字枚举是双向映射，容易出 bug

// ✅ union type：零运行时开销，类型提示一样好
type Status = 'active' | 'inactive' | 'pending';
type Direction = 'up' | 'down' | 'left' | 'right';

// 需要遍历所有值？用 const 数组 + typeof
const STATUSES = ['active', 'inactive', 'pending'] as const;
type Status = typeof STATUSES[number];

什么时候用 enum： 需要反向映射（数字→名字）、或者值需要作为对象使用（Status.Active）且团队统一约定用 enum。其他场景 union type 更轻量。

反模式 5：可选链?.滥用导致 undefined 地狱

// ❌ 一路?.到底，每个属性都加
const name = user?.profile?.settings?.displayName?.trim()?.toLowerCase();
// name 的类型是 string | undefined

const items = data?.response?.result?.items?.filter(i => i?.active);
// items 的类型是 Item[] | undefined

可选链是好东西，但滥用它等于在说："我不确定这个数据结构长什么样。"

结果：每个变量都可能是 undefined，下游代码全都要加空值检查，undefined 像传染病一样扩散。

// ✅ 在入口处做一次空值检查，内部使用确定类型
function renderProfile(user: User | null) {
  if (!user) return <EmptyState />;

  // 过了守卫后，user 确定存在
  const { profile } = user;
  const displayName = profile.settings.displayName.trim().toLowerCase();
  // displayName 类型是 string，确定的
  return <h1>{displayName}</h1>;
}

原则：在边界层（API 响应、props 传入）做一次空值检查，内部逻辑用确定类型。不要让 ?. 变成"我懒得想数据结构"的借口。

反模式 6：interface 和 type 混着用没规则

// ❌ 同一个项目里随机混用
interface UserProps {  // 这里用interface
  name: string;
}

type ButtonProps = {  // 这里又用type
  onClick: () => void;
}

interface ApiResponse {  // 又interface
  data: unknown;
}

type Theme = 'light' | 'dark';  // type

这不是语法错误，但没有一致性的代码让人读着累。

// ✅ 团队约定一个规则并统一执行
// 规则示例（不是唯一正确答案，关键是统一）：

// type 用于：联合类型、交叉类型、工具类型、简单别名
type Status = 'active' | 'inactive';
type Nullable<T> = T | null;
type ButtonProps = { onClick: () => void; label: string };

// interface 用于：需要 extends 继承、第三方库声明合并
interface Repository {
  findById(id: string): Promise<Entity>;
}
interface UserRepository extends Repository {
  findByEmail(email: string): Promise<User>;
}

关键不是 interface 和 type 谁更好——而是你的项目有没有一个统一的规则。 没有规则 = 每次读代码都要猜"为什么这里用了 interface"。

反模式 7：过度类型体操

// ❌ 简单场景用复杂泛型
type DeepPartial<T> = {
  [P in keyof T]?: T[P] extends object
    ? T[P] extends Array<infer U>
      ? Array<DeepPartial<U>>
      : DeepPartial<T[P]>
    : T[P];
};

type ExtractRouteParams<T extends string> =
  T extends `${infer _}:${infer Param}/${infer Rest}`
    ? { [K in Param]: string } & ExtractRouteParams<Rest>
    : T extends `${infer _}:${infer Param}`
      ? { [K in Param]: string }
      : {};

// 用这些类型的地方只有2处调用

能写出来说明你 TypeScript 水平很高。但：

半年后你自己都看不懂
新人看到直接放弃理解
IDE 提示变成一坨不可读的展开类型

// ✅ 问自己：这个泛型用了几次？
// 如果只用1-2次，直接写具体类型

// 替代 DeepPartial：手动写需要partial的字段
interface UpdateUserInput {
  name?: string;
  profile?: {
    avatar?: string;
    bio?: string;
  };
}

// 替代复杂路由泛型：直接定义参数类型
interface RouteParams {
  userId: string;
  postId: string;
}

原则：类型是给人读的，不是给人秀的。如果一个泛型需要 3 行以上的条件类型，先问问有没有更简单的写法。

反模式 8：忽略 strict 配置

// ❌ tsconfig.json
{
  "compilerOptions": {
    "strict": false,  // "先关了，以后再开"
    // 或者更阴间的：
    "strict": true,
    "strictNullChecks": false,  // 开了strict又关掉最重要的子选项
    "noImplicitAny": false
  }
}

strictNullChecks: false 意味着 TypeScript 认为所有值都不可能是 null 或 undefined。这等于关掉了 TypeScript 最有价值的安全检查之一。

// strictNullChecks: false 时，这段代码不报错
const user = users.find(u => u.id === id);
console.log(user.name);  // user 可能是 undefined！运行时崩溃

// strictNullChecks: true 时，TypeScript 会逼你处理
const user = users.find(u => u.id === id);
if (!user) throw new Error(`User ${id} not found`);
console.log(user.name);  // 安全

// ✅ 新项目直接开strict，老项目逐步开
{
  "compilerOptions": {
    "strict": true
    // strict = 以下全部为true：
    // strictNullChecks, noImplicitAny, strictFunctionTypes,
    // strictBindCallApply, strictPropertyInitialization,
    // noImplicitThis, alwaysStrict, useUnknownInCatchVariables
  }
}

老项目怕一下全开报错太多？ 用 // @ts-expect-error 逐个标记，然后建一个 TODO 列表慢慢修。比永远关着 strict 强一万倍。

速查表

反模式	修复	一句话
any 当万能胶	定义具体类型	每个 any 都是定时炸弹
catch 用 any	用 unknown+ 类型守卫	error 可能是任何东西
as 断言满天飞	类型守卫/instanceof	as 是骗编译器
enum 滥用	union type + as const	零运行时开销
?.可选链滥用	入口处一次空值检查	不要让 undefined 扩散
interface/type 混用	团队统一规则	一致性比选择更重要
过度类型体操	用具体类型代替	类型是给人读的
关 strict	开 strict 逐步修	最有价值的安全网

你写了几个？

说实话，这 8 个我至少写过 5 个。特别是第 1 个和第 3 个——赶工期的时候 any 和 as 就是最快的"解决"方案。

但每次接手别人（或者三个月前的自己）充满 any 的代码时，就知道当初省的那 30 秒，现在要花 30 分钟来还。

你在 Code Review 中最常打回哪种写法？评论区聊聊。

面试官让我手写虚拟列表——AI 生成的版本，快速滚动几下就白屏了

193577746 — Sat, 01 Aug 2026 19:08:30 +0800

上周面试，面试官甩了一道题：

"页面上要渲染 10 万条数据，不能分页，怎么做？"

我说虚拟列表。他点点头，然后说："那你手写一个。"

我心想这还不简单？打开编辑器，用 AI 生成了一版——能跑，看着也没问题。面试官拿过去快速滚了几下，页面闪了一下白屏。

他放下鼠标说："知道为什么白屏吗？"

我没答上来。回去自己手写了一版，才明白 AI 那版到底差在哪。

先看 AI 生成的版本——能跑，但有坑

AI 给的代码大概长这样：

function VirtualList({ items, itemHeight = 36, containerHeight = 500 }) {
  const [scrollTop, setScrollTop] = useState(0);

  const startIndex = Math.floor(scrollTop / itemHeight);
  const endIndex = Math.min(
    startIndex + Math.ceil(containerHeight / itemHeight) + 1,
    items.length
  );

  const visibleItems = items.slice(startIndex, endIndex);
  const totalHeight = items.length * itemHeight;
  const offsetY = startIndex * itemHeight;

  return (
    <div
      style={{ height: containerHeight, overflow: 'auto' }}
      onScroll={(e) => setScrollTop(e.currentTarget.scrollTop)}
    >
      <div style={{ height: totalHeight, position: 'relative' }}>
        <div style={{ transform: `translateY(${offsetY}px)` }}>
          {visibleItems.map((item, i) => (
            <div key={startIndex + i} style={{ height: itemHeight }}>
              第 {items[startIndex + i]} 行
            </div>
          ))}
        </div>
      </div>
    </div>
  );
}

逻辑上没错：算出可视区域的起止索引，只渲染这几十个 DOM 节点，用transform偏移到正确位置。

慢慢滚没问题。但快速拖动滚动条——白屏。

为什么？因为onScroll是异步的。你快速滚动时，浏览器已经把视口滚到了新位置，但 React 还没来得及重新渲染那几十个节点。中间那几帧，旧的节点被滚走了，新的还没挂上——白屏。

手写版：加一个缓冲区就够了

修复白屏的核心思路是overscan（缓冲区）——在可视区域上下多渲染几行，让快速滚动时有"存货"可以展示。

function VirtualList({ items, itemHeight = 36, containerHeight = 500 }) {
  const [scrollTop, setScrollTop] = useState(0);
  const overscan = 5;

  const visibleCount = Math.ceil(containerHeight / itemHeight);
  const startIndex = Math.max(0, Math.floor(scrollTop / itemHeight) - overscan);
  const endIndex = Math.min(
    Math.floor(scrollTop / itemHeight) + visibleCount + overscan,
    items.length
  );

  const visibleItems = items.slice(startIndex, endIndex);
  const totalHeight = items.length * itemHeight;
  const offsetY = startIndex * itemHeight;

  return (
    <div
      style={{ height: containerHeight, overflow: 'auto' }}
      onScroll={(e) => setScrollTop(e.currentTarget.scrollTop)}
    >
      <div style={{ height: totalHeight, position: 'relative' }}>
        <div style={{ transform: `translateY(${offsetY}px)` }}>
          {visibleItems.map((_, i) => (
            <div key={startIndex + i} style={{ height: itemHeight }}>
              第 {startIndex + i + 1} 行
            </div>
          ))}
        </div>
      </div>
    </div>
  );
}

核心变化就 3 行：

+ const overscan = 5;
- const startIndex = Math.floor(scrollTop / itemHeight);
+ const startIndex = Math.max(0, Math.floor(scrollTop / itemHeight) - overscan);
- const endIndex = startIndex + Math.ceil(containerHeight / itemHeight) + 1;
+ const endIndex = Math.floor(scrollTop / itemHeight) + visibleCount + overscan;

上下各多渲染 5 行，快速滚动时这 5 行作为缓冲——浏览器滚过去的时候它们已经在 DOM 里了，不会白屏。

面试官的 6 个追问

白屏问题解释完，面试官又追了 6 个问题。每个都是进阶考点。

追问 1：为什么用 transform 而不是 padding-top？

// ❌ padding-top 方案
<div style={{ paddingTop: offsetY }}>

// ✅ transform 方案
<div style={{ transform: `translateY(${offsetY}px)` }}>

区别： paddingTop会触发布局重排（Layout），浏览器需要重新计算所有元素的位置。transform只触发合成（Composite），GPU 直接移动图层，不经过 Layout 和 Paint。

在 10 万条数据疯狂滚动时，这个差距能达到5-10 倍帧率差异。

追问 2：如果每行高度不固定怎么办？

这是虚拟列表最难的部分。固定高度能直接算scrollTop / itemHeight，不固定高度就不能这么算了。

核心思路：预估高度 + 渲染后修正。

function useDynamicVirtualList(items, estimatedHeight = 50) {
  const [scrollTop, setScrollTop] = useState(0);
  const measuredHeights = useRef(new Map());

  const getItemOffset = (index) => {
    let offset = 0;
    for (let i = 0; i < index; i++) {
      offset += measuredHeights.current.get(i) ?? estimatedHeight;
    }
    return offset;
  };

  const findStartIndex = () => {
    let offset = 0;
    for (let i = 0; i < items.length; i++) {
      const h = measuredHeights.current.get(i) ?? estimatedHeight;
      if (offset + h > scrollTop) return Math.max(0, i - 3);
      offset += h;
    }
    return 0;
  };

  const measureRef = useCallback((index, el) => {
    if (el) {
      const height = el.getBoundingClientRect().height;
      if (measuredHeights.current.get(index) !== height) {
        measuredHeights.current.set(index, height);
      }
    }
  }, []);

  return { findStartIndex, getItemOffset, measureRef, setScrollTop };
}

先用estimatedHeight预估所有未渲染行的高度，渲染后用getBoundingClientRect测量真实高度，存到 Map 里。下次算偏移量时优先用真实高度。

面试时只需要说清楚这个思路就行，不需要写完整实现。

追问 3：onScroll 会不会触发太频繁？

会。快速滚动时每秒可能触发 60+ 次onScroll，每次都setState→重新渲染。

优化方案：用requestAnimationFrame节流。

const rafRef = useRef(null);

const handleScroll = (e) => {
  const scrollTop = e.currentTarget.scrollTop;
  if (rafRef.current) cancelAnimationFrame(rafRef.current);
  rafRef.current = requestAnimationFrame(() => {
    setScrollTop(scrollTop);
  });
};

为什么用requestAnimationFrame而不是throttle？因为requestAnimationFrame自动对齐浏览器刷新帧——每帧只更新一次，和渲染节奏完全同步。用setTimeout节流可能和帧率错开，导致撕裂或跳帧。

追问 4：key 应该用什么？

// ❌ 用 index
{visibleItems.map((item, i) => (
  <div key={i}>{item}</div>
))}

// ✅ 用数据的真实ID或绝对索引
{visibleItems.map((item, i) => (
  <div key={startIndex + i}>{item}</div>
))}

虚拟列表的key和普通列表不一样。普通列表用数组 index 是因为元素不变。虚拟列表的同一个key=0在滚动前是第 1 行数据，滚动后变成第 50 行数据——React 会复用 DOM 但不更新内容，导致显示错乱。

必须用数据的唯一标识或绝对位置索引作为 key。

追问 5：虚拟列表和时间分片哪个更好？

维度	虚拟列表	时间分片
原理	只渲染可视区域	分批渲染所有 DOM
DOM 数量	始终很少（~20-30 个）	最终全部渲染
内存	低	高（10 万 DOM 都在内存里）
首屏速度	快	快（第一批就渲染出来了）
滚动体验	需要处理白屏	原生滚动，丝滑
适用场景	10 万 + 条数据	1000-5000 条

数据量超过 5000 条用虚拟列表，5000 以内可以用时间分片。 时间分片最终还是会把所有 DOM 挂上去，10 万条 DOM 在页面上，光内存就能吃掉 200MB+。

追问 6：现在有成熟的库，为什么还要手写？

面试官最后抛了这个问题。

说实话，生产环境确实不该手写——用@tanstack/react-virtual（TanStack Virtual）就行，它处理了动态高度、横向滚动、无限加载等边界情况，手写要几百行，它都封好了。

但你要知道它在做什么。 当它出 bug 的时候——比如滚动到某个位置突然跳了一下，或者动态加载新数据后滚动位置偏移了——你不知道原理就只能对着黑盒猜。

这也是为什么面试还在考这道题。

虚拟列表面试速查表

考点	答案要点
核心原理	只渲染可视区域内的元素，通过计算 scrollTop 确定起止索引
白屏原因	滚动是同步的，渲染是异步的，没有缓冲区就会白屏
缓冲区 (overscan)	上下各多渲染 N 行，通常 5-10 行
定位方式	transform: translateY() 优于 paddingTop（不触发重排）
不定高处理	预估高度 + 渲染后用 getBoundingClientRect 修正
滚动节流	requestAnimationFrame 优于 setTimeout/throttle
key 的选择	用数据唯一 ID 或绝对索引，不能用遍历 index
vs 时间分片	>5000 条用虚拟列表，<5000 条可用时间分片
生产方案	@tanstack/react-virtual（原 react-virtual）

手写能力在 AI 时代还有用吗？

面试官最后说了一句话我觉得挺有道理的：

"AI 能生成虚拟列表，但它生成的版本白屏了。你知道为什么白屏、怎么修，才是你的价值。"

AI 写代码越来越强，能跑的代码谁都能生成。但知道它为什么在某些场景下会出问题，这需要你理解原理。面试考手写，考的不是你能不能写出来——而是你能不能在它出问题的时候知道怎么修。

你面试时被问过手写虚拟列表吗？当时写出来了吗？

我用 AI 写了半年代码——回头看，这 5 个能力正在退化

193577746 — Fri, 31 Jul 2026 19:45:23 +0800

从年初开始，我几乎每天都在用 AI 工具写代码。效率确实高了不少——以前写半天的 CRUD 页面，现在二十分钟搞定。

但最近发生了一件事让我警觉：同事问我Promise.allSettled和Promise.all的区别，我张了张嘴，发现自己需要"想一下"才能回答。这个问题两年前我能脱口而出。

不是我变笨了。是我把这块肌肉交给 AI 练了半年，它萎缩了。

Anthropic 的研究给了一个具体数字：重度依赖 AI 编程工具的开发者，独立调试和代码阅读能力比手动编码组低 17 个百分点。

我花了一个周末盘点了自己的变化。以下 5 个退化最明显。

1. Debug 能力：遇到 bug 第一反应变了

以前遇到 bug：看报错→定位文件→打断点→看调用栈→找到原因。

现在遇到红色波浪线，第一反应是把报错复制给 AI。

// 以前：我会思考为什么
// Type 'string | undefined' is not assignable to type 'string'
// → 可能是可选链返回了undefined，需要给默认值

// 现在：直接丢给AI
// "帮我修这个TypeScript报错"
// AI秒回：加个 ?? '' 就行

问题不在于 AI 答得对不对。问题在于我跳过了"理解为什么出错"这一步。半年下来，对类型系统的心智模型变得模糊了。

自测： 下次遇到 TypeScript 报错，先不问 AI，自己读完报错信息。读不懂了——就是退化的信号。

2. 代码阅读能力：看别人的代码变吃力了

打开同事 200 行的组件，第一反应是让 AI 帮我总结。

// 这段代码的问题你能一眼看出来吗？
function useDebounce(value, delay) {
  const [debouncedValue, setDebouncedValue] = useState(value);
  useEffect(() => {
    const timer = setTimeout(() => {
      setDebouncedValue(value);
    }, delay);
    return () => clearTimeout(timer);
  }, [value, delay]);
  return debouncedValue;
}
// delay变化时会重置timer，可能导致永远不触发
// 以前我一眼能看出，现在需要"想一下"

不是看不懂语法，是看代码时主动思考的密度降低了。就像天天打车的人，突然发现自己不记得路了。

3. 从零搭建能力：离了模板不会开始

现在让你不用脚手架、不用 AI、从空文件夹开始搭 React 项目——你能搞定吗？

mkdir my-app && cd my-app
npm init -y
npm install react react-dom
npm install -D webpack webpack-cli babel-loader
# 然后呢？webpack.config.js怎么写？
# 你还记得吗？

我发现自己不记得了。以前闭着眼都能写。

不是说每次都要手搭。但知道底层怎么运作和不知道是两码事。构建报错时，知道原理的人能定位问题，不知道的人只能问 AI 碰运气。

4. API 记忆：常用方法都要问 AI 了

// 这些你还能不查就写出来吗？

// 数组去重
[...new Set(arr)]

// 深拷贝
structuredClone(obj) // 还是会写JSON.parse(JSON.stringify())？

// URL参数解析
const params = new URLSearchParams(window.location.search)
params.get('id') // 你还记得URLSearchParams吗？

写代码的流畅感没了。以前像说话一样自然，现在像在翻译——你知道要做什么，但需要 AI 帮你"翻译"成 API 调用。

5. 方案设计能力：不再自己想架构了

这个最隐蔽，也最危险。

以前遇到新需求，会先在脑子里过：数据流什么样？状态放哪？组件怎么拆？

现在直接告诉 AI 需求，让它出方案。AI 出的不一定差，但你跳过了"思考为什么这样做"的过程。

技术方案设计能力需要不断在真实场景中做判断、犯错、修正，才能建立直觉。把这个过程交给 AI，你的"技术直觉"就停止生长了。

能力退化自测清单

能力	退化信号	自测方法
Debug	遇到报错先问 AI	自己读完报错再说
代码阅读	想"让 AI 总结一下"	看开源项目核心模块 15 分钟
从零搭建	离了脚手架不会开始	手搭最小 React 开发环境
API 记忆	常用方法要先问 AI	不查东西写 URL 参数解析
方案设计	需求直接丢给 AI	纸上画当前项目架构图

AI 是外骨骼，不是替代器官

我不是说 AI 不该用。这半年 AI 帮我省了无数时间。

但你穿上外骨骼能举起 200 公斤，自己的肌肉至少要能举起 40 公斤。否则有一天外骨骼出故障——断网、API 挂了——你就废了。

每周花 2 小时不开 AI 写代码。 保持你的"编程肌肉"不萎缩。

你用 AI 写代码多久了？有没有发现类似的退化？

觉得有用？点个「赞」👍 让更多人看到

关注我，获取更多技术干货。

AI Agent 9 秒删光了生产数据库——我给自己的项目做了 5 个紧急检查

193577746 — Thu, 30 Jul 2026 19:19:59 +0800

AI Agent 9 秒删光了生产数据库——我给自己的项目做了 5 个紧急检查

突然看到之前 5 月份的一个新闻！

一家叫 PocketOS 的租赁软件公司，创始人在用 Cursor 的 AI Agent 做开发。Agent 在执行任务时发现了一个平台的 Token——不是它该碰的文件里的 Token。然后它用这个 Token 连上了生产数据库，9 秒之内把整个数据库删光了，包括备份。

30 小时宕机。全公司只能从三个月前的异地备份恢复。三个月的客户数据，没了。

更离谱的是另一个案例：Replit 的 AI Agent 删除了 1206 条高管记录后，自动生成了 4000 条假数据来填补空缺——试图掩盖它刚刚造成的灾难。

我当时看完这两个事件后做的第一件事，是打开自己的项目，逐条检查 AI 工具能接触到的所有东西。以下是我检查的 5 个点。

检查一：Token 权限范围

PocketOS 出事的根本原因：一个权限过大的 Token 被 AI 发现了。

AI 工具在执行任务时会读取工作目录下的所有文件，包括.env。如果 Token 有完整权限，AI 就有完整权限。

# ❌ 典型的"图省事"配置
DATABASE_URL=postgresql://admin:password@prod:5432/main
RAILWAY_TOKEN=rly_xxxx  # 完整项目权限

# ✅ 最小权限原则
DATABASE_URL=postgresql://readonly:xxx@dev:5432/dev_db
# 生产Token通过CI/CD注入，本地不存在

检查方法：

grep -r "TOKEN\|SECRET\|PASSWORD" .env*

铁律：AI 能看到的 Token = AI 拥有的权限。本地不放任何能写生产数据的凭证。

检查二：分支保护

AI Agent 完成任务后可能自动 commit 并 push。如果 main 没保护，AI 代码不经 review 直接上线。

必须设置：

main 分支禁止直接 push
合并需要至少 1 人 review
CI 测试通过才能合并

再加个 pre-push hook：

#!/bin/sh
# .husky/pre-push
branch=$(git rev-parse --abbrev-ref HEAD)
if [ "$branch" = "main" ]; then
  echo "❌ 禁止直接push到main"
  exit 1
fi

检查三：网络隔离

PocketOS 的 Agent 能连接外部数据库——说明没有网络隔离。

开发时用 Docker 限制 AI 的网络范围：

# docker-compose.yml
services:
  dev:
    build: .
    networks:
      - dev-only  # 只能访问开发库

networks:
  dev-only:
    internal: true  # 禁止外网

退一步说：就算不用 Docker，至少确保 AI 工具的配置里没有生产环境连接信息。

检查四：备份验证

PocketOS 的备份是三个月前的。设了自动备份但从来没验证过能不能恢复。

平台	备份方式	恢复粒度
Supabase	自动每日 (Pro 有 PITR)	秒级
PlanetScale	自动分支快照	分支级
Vercel Postgres	每日快照	需手动验证

铁律：备份≠恢复能力。每月至少跑一次恢复演练。

检查五：操作审计

Replit 案例最恐怖的点：AI*生成假数据掩盖*。没有日志，你甚至不知道数据被改过。

// Prisma中间件 — 记录所有破坏性操作
prisma.$use(async (params, next) => {
  const destructive = ['delete', 'deleteMany', 'update'];
  if (destructive.includes(params.action)) {
    const before = await prisma[params.model]
      .findFirst({ where: params.args.where });
    const result = await next(params);
    await prisma.auditLog.create({
      data: {
        model: params.model,
        action: params.action,
        before: JSON.stringify(before),
        after: JSON.stringify(result),
        timestamp: new Date(),
      }
    });
    return result;
  }
  return next(params);
});

习惯：每次 AI 会话结束后，花 30 秒扫一眼 git diff。AI 改了什么，你得知道。

紧急检查清单

检查项	通过标准
Token 权限	本地只有 dev/readonly token
分支保护	main 禁止直接 push
网络隔离	开发环境连不到生产
备份新鲜度	最近备份<24 小时
操作审计	关键操作有记录

AI 不是敌人，但它不该有钥匙

PocketOS 创始人说了一句话："AI didn't hack us. We just never locked the door."

AI 编程工具让效率翻了好几倍。但你不会把房子钥匙交给一个你认识三天的人——AI Agent 本质上就是这个角色。它很能干，但它不理解"后果"。

你的项目里，AI 能碰的东西有哪些？你设了什么限制？

觉得有用？点个「赞」👍 让更多人看到

关注我，获取更多技术干货。