现代网页代码评审该看哪些细节前端评审不是逐行找出“写法不够漂亮”的地方。它要帮助团队发现会让用户失败、让数据泄露或让以后无法修改的变化。一次有效的评审应当先理解这个改动影响了哪条用户路径再检查实现是否把边界交代清楚。从变更的入口开始读先看路由、组件入口和数据来源。页面是否在服务端或客户端执行数据是否来自可信接口加载、空数据、权限不足和请求失败时各展示什么如果改动涉及表单提交按钮是否会重复触发离开页面会不会丢失输入后端返回的字段错误能否定位到对应控件。const [submitting, setSubmitting] useState(false); async function submit() { if (submitting) return; setSubmitting(true); try { await createOrder(values); } finally { setSubmitting(false); } }这段代码只解决了界面的重复点击。接口仍应有幂等约束网络中断后用户再次提交时也不能创建两笔订单。评审时别把“按钮 disabled”误认为完整保护。关注浏览器与服务端的交界SSR 应用要避免在首屏渲染时直接依赖window、localStorage、当前时间或随机数否则服务端 HTML 和客户端首次渲染可能不同。确实需要浏览器信息时把逻辑放进 effect或在服务端传入稳定的初始数据。使用缓存时要核对缓存键是否包含语言、登录身份、租户和权限范围错用共享缓存会让别人的内容出现在不该出现的页面上。对富文本、URL 参数和第三方返回内容先按不可信输入处理。不要为了方便使用危险的 HTML 注入链接跳转应限制协议文件下载和预览要有类型、大小及权限校验。前端校验改善体验真正的权限判断仍在服务端。性能问题要能解释给用户评审时检查大列表是否虚拟化、昂贵计算是否每次渲染都执行、图片是否有尺寸与懒加载策略、事件监听是否在卸载时清理。不要机械地到处加 memo先确认引用变化和渲染热点。对于异步请求组件卸载后不应继续覆盖新页面的状态多个请求并发时要规定以哪个结果为准。最后看测试是否覆盖本次改动真正改变的行为权限分支、失败提示、键盘操作、窄屏布局与主要浏览器。评审意见应指出风险和预期行为而不是要求作者改成个人偏好的语法。代码评审的价值是让上线后的问题少一点、定位快一点。当改动较大时最好让作者在说明里写出验证过的场景和未覆盖的风险。评审者据此补充最需要的测试而不是在长 diff 中猜测每个分支的意图。这样反馈更具体也更容易在下一次交付中被采纳。对实验开关、埋点和迁移代码也要追问清理时间与所有者。临时分支长期留在页面里会让之后的每次修改都变得更难读。