# 1. 事件溯源（Event Sourcing）场景下事件命名如何同时满足业务可读性与版本向前兼容要求；列举常见的"动词过去时"与"业务结果型"两种命名风格的取舍 A 事件名应使用"命令式"（如 PlaceOrder），因为事件描述的是要做的动作 B 事件应表达"已发生的事实"，配合 schemaVersion 字段可保证向前兼容，且命名宜遵循团队统一语言 ✓ 正确答案 C 事件名一旦写入事件存储后仍可随意修改，以适配新业务 D 事件名与业务无关，只与数据库表名一致即可
# 2. 命名抽象层级与运行时副作用方向不一致时（如"Validator"实际包含副作用），如何通过命名反映真实意图，避免读者形成错误心理模型 A 让名字与行为对齐：拆分纯校验与带副作用的命令，并用动作动词命名副作用方法 ✓ 正确答案 B 保留原名字，因为校验过程中写库是内部实现细节 C 把校验方法改为返回 void 以隐藏副作用 D 删除 Validator 类直接在主流程中内联校验
# 3. 在 DDD 战略设计中如何通过统一语言（Ubiquitous Language）保证代码标识符、聚合根、领域事件命名与领域专家用语一致；举例说明订单→账单→结算链路中常见的命名漂移与修复路径 A 统一语言只影响文档，不影响代码标识符 B 统一语言要求代码类名、事件名、状态枚举与专家术语一致，漂移时通过术语表 + 工作坊 + CI 修复 ✓ 正确答案 C 代码标识符应先于领域专家用语确定，避免专家影响开发 D 每个团队都应使用各自独立的术语，无需统一
# 4. 大型组织多个团队独立演化同名聚合时，如何通过命名空间、Bounded Context 前缀或包名隔离防止语义冲突 A 让所有团队统一使用同一个 `Order` 类，避免分裂 B 通过包名/命名空间与 Bounded Context 前缀隔离，并用 ACL 与依赖方向约束跨上下文访问 ✓ 正确答案 C 禁止不同上下文使用相同概念名 D 把同名聚合合并到一个巨型类中
# 5. 重构遗留系统时如何不中断调用方地渐进式重命名；举例说明使用 deprecation alias、IDE 重构与编译器告警的协同 A 直接全局搜索替换旧名为新名并一次提交 B 新名 + 旧名别名并存，标记 @Deprecated 并通过编译器告警引导迁移，待调用量归零后再移除旧名 ✓ 正确答案 C 只改方法体内逻辑，不改方法名 D 删除旧方法，让调用方自行修复
# 6. "Three-state boolean"——使用 boolean + null 表示三态（未知/是/否）相比枚举（TriState）的可读性与误用风险 A 它比枚举三态更类型安全，应是首选 B 枚举三态无法表达"未知"状态 C 三态只能通过 null 表达 D 它把"未知"塞进 null，语义易混且自动拆箱有误用风险，宜用枚举或 Optional 显式表达三态 ✓ 正确答案
# 7. "magic boolean parameter"问题中 methodName(arg1, true, false) 的可读性陷阱及替代命名（enum/builder） A 用枚举、参数对象或 Builder 把布尔语义显式化到调用点 ✓ 正确答案 B 保持原样，因为布尔参数简单高效 C 把布尔参数改成字符串常量 D 删除多余参数，只保留一个布尔
# 8. 命名时如何区分"描述实现"与"表达意图"，举出至少三个典型反例与正例？ A 命名应描述实现细节，便于读者了解数据结构 B 命名越短越好，含义无关紧要 C 实现型命名与意图型命名等价，无差别 D 命名应表达业务意图，实现变更时名字仍准确，抗变化 ✓ 正确答案
# 9. boolean 变量命名（is*/has*/can*/should*）的常见陷阱；给出在 Java/Go/TypeScript 中容易引发误解的反例 A Java 中应统一使用 is 前缀，Go 也应如此 B boolean 命名前缀无关紧要 C 前缀语义要与实际含义匹配，且要符合语言惯例（Go 省略 is、TS 避免与类型守卫混淆） ✓ 正确答案 D should 前缀表示"必选"，与 is 等价
# 10. i18n / l10n 场景下命名应基于"业务概念"还是"展示文本"；如何避免将多语言展示词作为代码标识符造成的歧义 A 用语义化业务概念（如 orders.confirm）作为 key，展示文本放翻译文件 ✓ 正确答案 B 用展示文本（如"确认订单"）作为 key，直观 C 用语言的英文文案作为 key D 用字符串本身的哈希作为 key
# 11. 业务名词与数据库字段命名之间的转换规则；如何在领域层保留业务命名、避免 ORM 把数据库命名反向污染领域模型 A 领域模型字段应直接使用数据库字段名，保持同步 B 领域层用业务命名，数据库用其约定命名，通过 ORM 映射策略/注解转换，避免污染 ✓ 正确答案 C 数据库字段必须改成语义命名与领域一致 D 领域模型与数据库字段不允许重名
# 12. 可搜索性（grep-friendly）与可读性之间的张力；当用户常按"金额"搜索代码，但金额有 CNY/USD/Multiple 多种类型时如何命名以兼顾两者 A 全部用 `amount` 命名，不区分币种 B 用币种首字母作为变量名（如 u、c） C 每个币种用完全不同的随机词命名 D 用统一 Money 类型承载金额，字段命名统一 amount，币种类型化；或统一前缀 + 细分后缀 ✓ 正确答案
# 13. JSpecify 中 @Nullable、@NonNull 在标识符语义中的作用；命名如何与类型注解互补而非冗余 A 注解表达可空契约，命名表达业务意图，二者互补；命名不应重复注解信息 ✓ 正确答案 B 命名应重复注解的可空性（如 findUserOrNull） C 注解只影响文档，不影响语义 D 命名应替代注解，无需再写注解
# 14. Optional<T>、Maybe<T>、null 三种"无值"语义在 API 设计中的命名约定；避免 isPresent/get 双语义陷阱 A isPresent + get 是 Optional 的标准用法 B Optional 与 null 可以混用，无区别 C get() 永不抛异常，可放心使用 D 应优先用 orElse/orElseThrow/map 等安全 API，命名用 find 暗示可空、require 暗示必存，避免 get 双语义陷阱 ✓ 正确答案
# 15. boolean 命名歧义中 isValid、isCompleted、isActive 在并发场景下的非原子读取风险如何通过命名反映 A 命名体现"快照/时刻"语义，并用不可变值对象原子读取，避免逐字段非原子读取 ✓ 正确答案 B 继续用 is 前缀的布尔方法，名字暗示稳定即可 C 删除该状态，不再提供 D 用 volatile 单字段即可，无需命名调整
# 16. 方法命名（get*、find*、load*、fetch*）在 Spring/Guice 框架中的语义约定，对应 SQL 的 SELECT/UPDATE 副作用边界 A 四个前缀语义完全相同，可随意替换 B find 对应只读查询（SELECT），fetch 主动预取、load 可能触发懒加载，get 偏向直接获取；命名应与 SQL 副作用边界一致 ✓ 正确答案 C get 会触发数据库写操作 D fetch 表示删除操作
# 17. 值对象（Value Object）标识符设计中自增 ID、UUID、Snowflake、业务主键（手机号/邮箱）的取舍与命名一致性 A 自增 ID 永远优于 UUID，因为性能好 B 业务主键总是最优，因为带语义 C 主键统一命名为 id，业务标识（手机号/邮箱）用语义化字段名；选择依据是可读性、性能、分布式、安全性的权衡 ✓ 正确答案 D 标识符命名应与字段类型无关
# 18. HTTP API 字段命名（snake_case vs camelCase）与 JSON 序列化框架的兼容性 A 统一命名风格（如 snake_case），领域层保持语言惯例，序列化框架负责映射契约名 ✓ 正确答案 B 全仓混用命名风格，按需切换 C 必须用 camelCase，因为前端都用它 D 字段命名由前端随机决定
# 19. boolean 命名前缀（is/has/can/should/must/will）的语义分级与 RFC 2119 风格对照；状态类布尔（isActive 等）何时应改用枚举表达三态与状态流转？ A is/has/can/should/must 前缀表达不同强度的确定性，可类比 RFC 2119；状态超过二态或有流转约束时应改用枚举 ✓ 正确答案 B 所有状态都应用 isActive 式布尔表达 C 布尔前缀与状态无任何关系 D 状态类布尔应越加越多
# 20. 命名中暴露实现（userId、userUUID、userMongoId）的反模式与改造路径 A 保留，因为命名能提示存储细节 B 所有 ID 都叫 data C 把存储引擎名直接加进所有字段名 D 统一为领域语义命名（userId），需要时用类型化 ID 值对象，让存储细节隔离在持久化层 ✓ 正确答案
# 21. 团队命名规范的粒度中类/方法/变量/常量各自应遵循什么层级的规范？ A 所有命名都用一个规范，无差别 B 常量用 camelCase 即可 C 局部变量必须与类名一样长 D 类用名词、方法用动词、常量全大写、局部变量可短；可见性越广命名越完整语义化 ✓ 正确答案
# 22. 复数与单数的命名规约（user vs users、items vs itemList）在序列化层与领域层的差异 A 用 userList 更清晰，因为带类型 B 命名与集合类型无关 C 单数表示集合，复数表示单元素 D 领域层与序列化层都用复数集合名（users），避免 List 后缀类型泄漏 ✓ 正确答案
# 23. 时间戳命名（createdAt、updatedAt、deletedAt、occurredAt）的语义层级与时区标注 A 用 XxxAt 表达事件时刻，配合 UTC + Instant 类型承载时区，LocalDateTime 时命名注明 Local ✓ 正确答案 B 时间戳命名无需区分语义，统一用 time C 时间戳必须用无时区类型 D 时区只影响显示不影响存储
# 24. 金额命名（price、amount、total、fee）的精确语义中为何应统一为单一 Money 类型并携带币种，避免浮点精度与语义混用？ A 金额命名表达业务角色（price/amount/total/fee），统一用携带币种的 Money 值对象，用 BigDecimal 避免浮点精度 ✓ 正确答案 B 金额用 double 存储即可，无需统一类型 C 金额无需币种，因为业务固定用人民币 D 所有金额字段都叫 total
# 25. 集合命名中 List<User> users 与 Map<Role, List<User>> usersByRole 的对比，避免类型泄漏到标识符 A 用 userList、userMap 表达集合类型 B 用复数表达一组（users），用 ByXxx 表达分组（usersByRole），类型由声明承担不进名字 ✓ 正确答案 C 集合命名必须包含 List/Map 字样 D 集合命名与语义无关
# 26. 如何处理历史代码中的"坏命名"，直接重命名还是加注释过渡，风险如何控制？ A 一律加注释，保持旧名不变 B 坏命名不值得处理 C 每次重命名都大改逻辑 D 私有名直接重命名并测试；公共 API 用别名 + deprecation 渐进迁移，改名与逻辑分离、小步提交控制风险 ✓ 正确答案
