有些项目通过了构建，也能正常打开，但一改文案就影响多个页面；有些组件看似复用，里面塞满条件分支，最终没人敢动。代码规范的价值不在“看起来专业”，而在降低后续修改的风险和成本。
审核时应同时检查结构、类型、样式、数据、测试、性能、安全和文档，不能只跑一次格式化工具。
01 目录与模块边界是否能被解释
页面、组件、业务模块、数据、工具和资源应有清晰职责。一个文件过长不是唯一问题，更重要的是是否承担了多个互相无关的任务。
新成员应能快速找到页面入口和公共逻辑。
02 命名与类型是否表达真实含义
变量、函数、组件和接口命名要对应业务，不使用大量temp、data1或含糊缩写。TypeScript项目应减少无边界的any，并对外部数据做校验。
类型不是为了消灭所有报错，而是提前暴露不一致。
03 组件复用不是越多越好
真正复用的是稳定规则。若一个“万能组件”依赖几十个布尔参数，维护成本可能高于适度拆分。
页面结构、交互状态和样式变体应有清楚接口。
04 样式系统要避免局部修补失控
颜色、字体、间距和断点应有统一来源。大量!important、复制粘贴和页面级覆盖通常意味着规则没有被抽象。
但也不应为一个只出现一次的样式强行建立复杂系统。
05 自动检查需要覆盖真实风险
至少应有格式、Lint、类型检查、构建和关键流程测试。表单、路由、权限或支付等重要逻辑需要更具体的测试。
检查命令必须在干净环境可复现，而不是只在某台电脑通过。
06 性能、安全与交接是代码质量的一部分
资源加载、错误处理、依赖更新、密钥管理、日志和第三方脚本都应被检查。README应说明运行、构建、部署、环境变量和常见操作。
企业需要拥有仓库、部署和服务账号的控制权。
代码规范审核维度
维度 | 合格表现 | 常见风险 |
|---|---|---|
结构 | 职责清晰、入口明确 | 文件堆放、循环依赖 |
类型与数据 | 接口明确、外部输入校验 | any泛滥、字段靠猜 |
组件与样式 | 稳定复用、规则统一 | 万能组件、覆盖失控 |
质量检查 | Lint、类型、构建、测试可复现 | 只靠人工点击 |
运行与交接 | 文档、权限、部署可接管 | 账号归属不清 |
常见问题
代码行数越少越规范吗？
不是。过度压缩和抽象同样会降低可读性，应以职责和变更成本判断。
网站必须使用TypeScript吗？
不是绝对要求，但复杂项目使用类型系统通常更利于协作和长期维护。
没有单元测试是否一定不合格？
小型展示站可按风险决定，但关键表单、数据和业务流程应有相应验证。
是否应该删除所有重复代码？
只有稳定、语义相同的重复才适合抽象，过早复用可能制造更复杂的依赖。
代码审核需要检查第三方依赖吗？
需要，包括版本、安全风险、许可证、维护状态和是否真正必要。
链接复制成功
