主题
工程体系
这些题与问题库里的是同一批，这里按各自主要考察的能力分组。
97 道问题
本页为第 51–97 题，共 97 题。
A · 专业解题与实现19
- 构建仓库需要清理多年积累的镜像，但线上仍有服务依赖旧版本回滚。你会如何确定保留策略和制品可恢复要求？
- 组织要把多个仓库从旧的自动构建与检查平台迁到新平台，但团队不能同时停下交付。你会怎样分批迁移，并判断哪些仓库可以进入下一批？
- 数百个仓库都锁定了不同版本的第三方依赖，安全团队发现高危漏洞时很难知道影响范围。你会怎样建立依赖更新和风险处置机制？
- 一个缺陷只在线上出现，开发和预发环境都无法复现。你会如何判断问题来自环境差异、流量形态还是数据特征，并改进环境设计？
- 一个关键完整流程测试偶尔失败，团队开始重跑直到通过。你会怎样确定它是否真实暴露产品风险，并改进测试流程？
- 用户更新后偶尔加载到新 HTML 和旧 JavaScript，页面因此报错。你会怎样设计静态资源命名、缓存策略和发布顺序来降低不一致？
- 多个团队把脱敏数据复制到开发、预发和性能环境，数据刷新频率各不相同。你会怎样设计测试数据的权限、生命周期和可复现性？
- 多个团队共享仓库却有不同发布节奏，公共包变更经常阻塞无关团队。你会如何设计边界、影响分析和发布约定？
- 同一版本在不同集群表现不同，配置变更又没有完整审计。你会如何建立配置来源、差异检测和回滚能力？
- 创建、编辑和审核由不同团队负责，表单反馈逐渐不一致。你会如何决定哪些模式统一、哪些保留差异？怎样检查加载、空白、错误和恢复状态？
- 多个团队复制共享组件并增加自有变体，产品体验逐渐不一致。你会如何判断哪些差异应进入共享设计系统，哪些应保留为团队特例？怎样让团队参与规则维护？
- 一个共享库发布了向后兼容的版本，但多个应用仓库因依赖锁定、生成代码或发布窗口不同，无法及时升级；安全修复因此被长期阻塞。你会如何设计兼容策略和依赖升级流程？
- 同一提交在开发者本地稳定通过，但自动构建与检查流程偶尔因时区、随机顺序、共享缓存或并行竞争而失败。你会如何分类、复现并减少这类不稳定问题？
- 一个功能已全量发布，但多年未清理的开关仍控制多个代码分支；团队不清楚哪些开关可删除，回滚时也依赖人工记忆。你会如何建立开关生命周期和清理责任？
- 多个团队可独立发布微前端模块，但页面加载、导航、错误提示和无障碍行为开始不一致。你会如何决定哪些能力由平台统一、哪些留给业务团队？
- 后端 API 同时生成 TypeScript、Java 和 Swift SDK，各语言的可空类型、枚举和错误模型逐渐不一致。你会如何设计接口约定源、生成流程和跨语言兼容测试？
- 生产环境发现一个依赖包与仓库标签对应的构建产物校验值不一致，团队无法确认来源是否经过预期的自动检查与构建流程。你会如何建立构建追溯、制品校验和发布授权？
- 新客户端已切到新版 API，但用户长期不升级，旧版本仍占有明显流量；继续兼容又限制服务端演进。你会如何确定支持窗口、能力探测、迁移提醒和停止服务的条件？
- 多个产品团队通过 CSS 覆盖共享组件样式，升级后频繁回归。你会如何判断应增加配置、拆分组件还是保留例外？
当前目标在这里暂无匹配题。 ·
B · 业务理解与领域建模8
- 一个数据库字段已被新字段取代，但仍有报表、导出和外部集成在读取旧字段；直接删除会造成静默错误。你会如何规划兼容迁移、消费方确认和最终删除？
- 业务报表需要统计每次状态变更的耗时，运营页面只需显示对象当前状态；团队把两者放进同一张宽表后，更新覆盖了历史。你会如何拆分事实、快照和当前状态模型？
- 业务分类会新增、合并或改名。历史报表既要按当时定义复现，也要按当前规则比较。你会怎样保存原始分类、映射版本和报表定义？
- 系统将内部用户主键从邮箱改为不可变 ID，但移动端缓存、合作方回调和历史导出仍引用邮箱。你会如何设计映射、双读期、隐私清理和旧引用失效策略？
- 多个团队各自定义了用户状态事件，平台计划统一为新的事件模型；某些消费者依赖旧字段的特殊含义，无法一次迁移。你会如何建立兼容适配、并行校验和弃用治理？
- 新模型要求新增特征并调整旧特征含义，线上特征服务还要同时支持旧模型回滚。你会如何版本化特征接口约定、部署顺序、双读成本和退役条件？
- 订单、库存和积分分别由不同服务维护，消息可能重复、乱序或延迟。你会怎样识别事件、避免重复记账并记录补偿？
- 一个产品线拆成两个业务单元，历史订单仍属于旧组织，未来订单按新组织归属。你会怎样表达组织版本和历史视图？
当前目标在这里暂无匹配题。 ·
C · 价值判断与方向规划8
- 过去一年，你为解决技术债（累积的维护和改造问题）或改善构建、发布等工程基础设施争取过多少团队投入？当这些问题拖慢产品迭代时，你怎样向业务负责人说明影响和风险，并争取重构时间？
- 新平台可以减少未来开发成本，但旧系统仍需维护两年；本季度预算只能支持一项完整投入。你会怎样比较建设、迁移和维持现状的组合？
- 老板或业务方强压排期，说"先上线，代码写得烂点没关系"。作为负责人，你怎样应对？哪些质量可以让步，哪些不能，你怎样让这种让步是公开、有期限的，而不是悄悄变成永久的债？
- 业务想要新功能，团队又积累了不少技术债。你怎样决定这个季度各投入多少？
- 讲一个你参与的技术平台改造项目：上线后使用团队很少，业务结果也不明显。你当时根据什么数据或假设决定投入？后来哪些判断被证据推翻，你增加了什么验证方式？
- 多个团队每月花大量时间人工处理部署配置问题。平台改造可以减少重复操作，但短期内不会直接增加收入；业务功能则有明确收入目标。你会如何判断哪些收益确实来自平台改造，并确定投入边界？
- 团队目前每月发布一次，业务要求缩短到每周，但自动化测试、回滚和监控尚不成熟。你会如何制定发布能力路线图，并避免只以部署频率作为成功标准？
- 团队可自建内部身份服务，也可采购供应商产品；自建能更贴合特殊流程，采购上线快但涉及迁移、合规和长期许可费用。你会如何比较全生命周期成本，以及供应商不合适时退出有多困难？
当前目标在这里暂无匹配题。 ·
D · 交付执行与持续运营4
E · 协作沟通与影响2
F · 人才与组织建设5
- 平台团队负责公共能力，但业务团队希望快速定制，平台积压越来越多。你会如何设计服务边界和协作方式？
- 某专家掌握核心系统的发布和恢复步骤，其他人只负责简单任务。你会如何降低单点依赖？
- 团队里有个有个性、技术不错的开发，不爱写单元测试，代码评审也敷衍。直接找他谈他可能嫌烦。你会用什么制度或机制去改变这种行为，又怎样让这些机制对所有人公开、公平？
- 团队从 6 人扩到 14 人后，原有分工仍沿用；成员对谁决定架构、谁支持运营和谁负责质量理解不同。你会如何重新建立团队约定？
- 技术浪潮更新很快。作为团队的技术带头人，你怎样避免团队因为长期维护公司的老旧自研系统而在外部市场上失去竞争力？你怎样平衡业务的稳定性和员工个人的技术市场价值？
当前目标在这里暂无匹配题。 ·
G · 学习适应与持续成长1
当前目标在这里暂无匹配题。 ·