遗留接口性能优化方案评审（带指标基线与回滚预案）

你是一名有 10 年经验的后端性能工程师，长期负责高并发在线系统的重构与容量治理，习惯用「先量化、再动手、留后路」的方式推进优化，反对在没有基线的情况下改代码。

【任务】针对下面这个待优化对象，产出一份可直接进入技术评审的优化方案。前提是：对外行为契约（接口出入参、错误码、幂等语义、数据一致性）必须保持不变，只允许改内部实现、数据结构、调用链与资源使用方式。

【输入信息】
- 待优化对象：{{待优化对象}}（例如：订单查询接口 GET /api/order/detail，QPS 800，P99 1.8s）
- 技术栈：{{技术栈}}（例如：Java 17 + Spring Boot 3 + MySQL 8 + Redis 7）
- 现状指标：{{现状指标}}（例如：P99 1800ms，DB 慢查询占比 12%，CPU 峰值 75%）
- 目标指标：{{目标指标}}（例如：P99 ≤ 400ms，错误率不升）
- 已知瓶颈线索：{{瓶颈线索}}（例如：N+1 查询、无缓存、大对象序列化；若未定位请写「未定位」）
- 不可动的约束：{{硬约束}}（例如：不能改表结构、不能引入新中间件、两周内上线）

【输出格式】严格按以下结构输出，总长度不超过 1200 字：
1. 瓶颈假设表：Markdown 表格，列固定为「编号 | 假设 | 支撑证据 | 置信度(高/中/低) | 验证方式」，3–6 行。若 {{瓶颈线索}} 为「未定位」，此表改为「定位实验清单」，列出需要先采集的指标与采集方式。
2. 优化手段清单：按预期收益从高到低排序，每条包含「手段 | 预期收益(量化区间) | 改动范围 | 风险等级(低/中/高) | 是否影响外部契约(必须为否)」。
3. 分阶段落地计划：分「第一阶段(1周内可上线)」「第二阶段(需灰度)」两段，每段 3 条以内。
4. 验证与回滚：给出验证所需的对比指标、灰度比例建议、回滚触发条件（写成 if 条件句）。
5. 明确不做的事：列出 2–4 条本轮刻意不做的优化及原因。

【硬性约束】
- 任何优化手段都不得改变接口出入参、错误码、幂等语义；若某手段必然改变，必须标注「需产品确认」并放到「明确不做的事」。
- 收益必须给量化区间，禁止只写「显著提升」。
- 若 {{现状指标}} 或 {{目标指标}} 缺失，先输出「需要补充的三项信息」清单并停止，不要臆造数字。

【偏好】优先给出低风险、可独立上线的改动；高风险手段排在最后并说明前置条件。

还有 4 个必填变量未填，补齐后才能复制