Code Review for Web 是一个面向 Web 应用代码的审查与调试技能，重点放在真正会导致生产环境出错的模式上。技能主体（SKILL.md）提供与技术栈无关的原则，具体技术栈的模式放在 references 参考文件中。
用途
该技能在以下场景使用：合并前审查拉取请求（PR）；调试生产问题；调查构建失败；审计既有代码的安全或性能；排查环境变量或配置问题；分诊“站点坏了”类报告。
不适用场景（技能中给出了替代方案）：编写新功能规格（改用 pm-spec-writing）；针对运行中站点的上线前 QA（改用 qa-testing）；针对 Core Web Vitals 的性能深入分析（改用 performance-optimization）；深度无障碍合规审查（改用 accessibility-audit）。
所需输入
审查对象：代码、PR、错误信息或症状；调试时需能访问日志（构建日志、函数日志、服务器日志）；技术栈信息（框架、托管、数据库），即使只是高层级说明也可以。若只提供症状（如“站点坏了”），工作流第一步就是先收集足够的上下文来开展调查。
五个审查维度
每次代码审查覆盖五个维度，深度视情况而定。
-
正确性：代码是否实现了它声称的功能。包括逻辑是否与规格或 PR 描述中的意图一致；是否处理空状态、错误状态、网络失败等边界情况；是否存在差一错误、空/未定义处理、异步竞态条件；是否有针对本次改动的测试，或说明为何没有；是否破坏既有功能（回归风险）。
-
安全：代码是否暴露敏感信息或打开攻击面。包括密钥处理（客户端代码或版本控制中不得出现密钥、API key、service-role 凭据）；鉴权检查（每个变更端点都要在行动前验证调用方）；输入验证（用户输入在用于查询、文件路径或 HTML 前需净化）；外部请求（校验出站 URL，避免用户可控输入导致 SSRF）；CSRF 防护（状态变更请求需令牌或同源策略）；速率限制（面向公众的变更端点要有速率限制）；仅 HTTPS（生产代码路径不得使用 HTTP）；Cookie（会话 Cookie 需设置 Secure、HttpOnly、SameSite）；环境变量（仅服务端使用的密钥不得加任何会将其暴露到客户端 bundle 的前缀）。
-
性能：代码能否扩展并保持快速。包括数据库查询（避免 N+1 模式，优先 join 或批量获取而非循环查询）；分页（大结果集要分页，不得全量加载）；缓存（缓存策略与数据新鲜度需求匹配）；bundle 体积（客户端依赖需有理由，tree-shaking 正常工作）；图片处理（现代格式、懒加载、显式尺寸）；后台任务（慢操作移出请求路径）；冷启动敏感度（频繁触发的冷路径需优化）。
-
可靠性：失败时会发生什么。包括错误处理（捕获并处理，而非吞掉；带上下文记入日志）；重试（网络调用对瞬态失败有重试逻辑）；超时（外部调用有显式超时，避免无限等待）；优雅降级（非关键路径失败不应导致页面崩溃）；幂等性（可能被重试的变更操作可安全重试）；日志（日志包含足够上下文，无需复现即可诊断）。
-
可维护性：半年后下一个人（或未来的自己）能否看懂。包括命名（函数和变量按“做什么”而非“怎么做”命名）；注释（解释为什么，而非做什么）；复杂度（一个函数只做一件事，200 行的函数承担过多）；重复（多处相同逻辑应抽取）；依赖（新增依赖需有理由，每个都是维护负担）；魔法值（不写字面量 60000，使用命名常量）。
常见缺陷模式（与技术栈无关）
构建与部署方面：构建时数据获取超时（静态生成期间查询数据库的路由在规模化时可能失败，若数据必须新鲜应标记为运行时渲染）；环境变量未传播（本地正常但生产出错，通常说明未加入生产环境）；预览与生产环境不匹配（预览正常但生产域名出错，常见原因是硬编码了特定于环境的 URL）。
URL 与域名问题：canonical 指向 staging 或预览 URL（由客户端暴露的环境变量选错域名导致，canonical 域名应来自仅服务端环境变量）；API URL 指向会回环的主域名（DNS 切换后主域名可能已服务不同应用，API 应放在专用子域名）；HTTPS 升级问题（混合内容会破坏浏览器的安全模型）。
缓存失效：部署后内容陈旧（缓存未失效，或失效需手动触发但未执行）；CDN 以相同文件名提供旧资源（替换资源时应始终使用新文件名或缓存破坏查询串）；缓存头过于激进（频繁变化的资源设置长 max-age 会让用户看到数小时甚至数天的陈旧内容）。
数据库与数据：N+1 查询（循环内查询，改为批量获取或 join）；表扫描缺少 limit（大表查询忘记 LIMIT）；连接池耗尽（并发连接过多，常见于并行路由的构建时获取）；未回填的 schema 迁移（新增 NOT NULL 列却未为既有行填充数据）。
图片处理：上传后图片不显示（CDN 缓存了旧文件名，替换时使用新文件名）；图片导致布局偏移（缺少 width/height 属性，应始终同时指定）；大图导致 LCP 慢（首屏图片未做尺寸或格式优化）。
外部集成：Bot 缓解阻塞服务器间调用（CDN 或防火墙挑战合法的自动化流量，可白名单服务器 IP 或对 API 端点禁用挑战）；生产触发 API 速率限制（本地流量小所以正常，需加入退避并了解速率限制）。
安全：未受保护的重新验证或管理端点（应始终要求密钥令牌）；URL 中的 PII（会出现在服务器日志、浏览器历史和 referrer 头中）；客户端 bundle 中暴露密钥（任何发送到浏览器的内容都是公开的）。
工作流
收集上下文（什么技术栈？什么坏了或正在审查？有日志吗？）；选择深度（小 PR 快速扫描，重大改动完整审查，生产事故深入排查）；按五个维度逐项检查，按严重程度标注问题（阻塞、重要、次要）；检查技术栈特定模式，参考相应技术栈指南；针对事故，找出最小的假设驱动修复，尽可能本地复现；撰写审查，正式审查使用 references/review-template.md 中的模板。
失败模式
技能列出若干应避免的失败模式：对 500 行 PR 说“看起来不错”（大 PR 只花 5 分钟等于没审查）；不运行代码就审查（有些缺陷只在运行时暴露，应拉取分支并运行）；过度关注风格（在格式上纠缠却漏掉逻辑缺陷）；对“内部”功能跳过安全审查（内部很快会变成外部）；把警告当装饰（构建警告常在依赖更新后变成生产错误）；不读完整错误信息就调试（堆栈跟踪第一行往往不是真正原因，要读完整）。
调试工作流
当报告生产问题时：读取完整错误信息，包括堆栈跟踪；检查托管平台的构建日志和函数日志（确切的失败行通常在这里）；确定最后一个可用版本（git log --oneline 并检查近期提交）；本地复现（确认是代码问题而非环境问题）；检查环境变量（尤其部署或 DNS 变更后）；检查缓存状态（在断定是代码缺陷前先强制缓存失效）；做最小修复（事故期间大重构会制造更多事故）；在生产验证（确认实际修复生效，而不仅是部署成功）；记录（根因是什么？什么本可预防？归档经验教训）。
输出格式
PR 审查：在 PR 上内联评论，必要时加摘要。正式代码审查：生成 code-review-[date].md 的 Markdown 文档，包含范围（审查了什么）、摘要（总体评估）、关键问题（阻塞项）、重要问题、次要问题、后续建议。事故：产出一份事后复盘文档，格式见 after-action-report。
参考文件
references/review-template.md（正式代码审查的 Markdown 模板）；references/nextjs-patterns.md（Next.js 的栈特定模式：App Router、ISR、Server Components、常见缺陷）；references/wordpress-headless-patterns.md（无头 WordPress 集成的栈特定模式）。