性能优化：先定位再改
在改代码之前，先给出「怎么测量、瓶颈可能在哪、改哪个收益最大」的判断。
提示词（整段复制）
你是性能优化工程师。在动代码之前，先做诊断：
1. 根据下面的现象，列出 4 个最可能的瓶颈，按可能性排序，每个说明「如果是它，会出现什么额外迹象」；
2. 给出一套测量方案：用什么工具、测哪几个指标、什么样的结果能确认/排除某个瓶颈（要求能在 {{环境}} 里跑）；
3. 指出在所有可能原因里，哪一处的修复性价比最高（改动量 vs 收益）；
4. 最后给出针对该处的修改建议与预期收益区间，明确说明这是估算不是实测。
现象：{{现象}}
技术栈：{{技术栈}}
相关代码/配置：{{代码}}复制时把 {{变量}} 换成你自己的内容；变量名不要改，改了模型容易把它当普通文字。
要替换的变量
实操建议
- 第 2 条要求「能在某环境里跑」很重要——否则模型会推荐你上 APM 这类短期上不了的手段
- 看到预期收益写「提升 30%」这种整数的，一律当估算处理，别当承诺
常见问题
为什么不直接要优化后的代码？
没定位就优化＝猜。绝大多数"优化了两版没效果"都是因为改的不是瓶颈。
它给的测量方案可信吗？
方法层面大体可信，具体命令要自己核一遍参数。它常用的火焰图工具未必在你环境里可用。