白皮书统一“写得快”与“改得稳”，明确简写适用边界（局部临时变量可简，跨域业务命名须展开），动态键名须配套声明、校验、文档三要素，并通过ESLint、TS类型、Prettier和CI工具链固化落地。
确立团队开发中关于简写方法与动态键名的工程化白皮书，核心不是罗列语法技巧，而是把“怎么写得快”和“怎么改得稳”统一成可执行、可检查、可传承的规则。它必须直面两个现实痛点：一是开发者为图省事滥用简写（如res代替response、val代替validatedUser），导致上下文丢失；二是动态键名（如obj[config.field]、data[`${prefix}_${id}`]）在缺乏约束时，极易引发运行时错误、类型丢失和调试困难。
明确适用边界：哪些场景允许简写，哪些必须展开
白皮书要给出清晰的“红绿灯”判断逻辑，而非一刀切禁止：
-
允许简写：仅限作用域极小、生命周期极短、上下文绝对明确的变量，例如循环内临时索引
i、数组解构中的[_, name]、Promise链中无歧义的then(res => ...)； -
强制展开：所有跨函数、跨文件、涉及业务语义的命名，如API响应对象字段、状态管理中的key、配置项标识符；特别强调：HTTP状态码映射表里的
200: 'ok'必须写成200: 'success'，避免用ok这种易歧义缩写； -
例外机制：允许在
types.ts或constants.ts中定义全局简写常量（如const HTTP_OK = 200），但使用处必须通过常量名引用，禁止直接写数字或字符串。
动态键名必须配套三要素：声明、校验、文档
不能只写obj[key]就完事。白皮书要求每个动态键名操作必须同时满足：
-
声明来源：键名变量必须有明确类型定义（如
type ValidKey = 'user' | 'order' | 'payment'），禁止any或string作为键类型； -
运行时校验：在访问前插入守卫逻辑，例如
if (!Object.keys(allowedKeys).includes(key)) throw new Error(`Invalid key: ${key}`)；对关键路径（如权限控制、路由跳转）必须启用此校验； -
文档绑定：所有动态键名的生成逻辑，必须在JSDoc中用
@param和@returns完整说明输入约束与输出范围，并自动同步至Swagger或内部API文档系统。
用工具链固化规则，不依赖人工记忆
白皮书本身是纸面约定，真正落地靠工具：
- 在ESLint配置中新增自定义规则，拦截
res/val/tmp等黑名单词出现在非局部作用域； - 利用TypeScript的
keyof与Record类型，在构建时强制校验动态键是否属于预设集合； - 将白皮书中的命名规范编译为Prettier插件或Code Action，当开发者输入
const res = ...时，编辑器自动提示“建议改为response并提供一键修复”； - CI流水线中加入静态扫描步骤，对未加校验的
obj[xxx]模式报警告，未达80%文档覆盖率的接口拒绝合并。
示例：从问题代码到白皮书合规改造
原始写法（高风险）：
const res = await api.getUser(id);const key = `cache_${Math.random()}`;
cache[key] = res;
白皮书改造后：
const userResponse = await api.getUser(id); // 展开语义const cacheKey = generateCacheKey('user', id); // 封装动态逻辑
validateCacheKey(cacheKey); // 运行时校验
cache[cacheKey] = userResponse; // 键名来源清晰、类型受控
