解决问题的思路
总体纲领 在coding之前 我们需要先有个draft(草案) 包含 背景 约束条件 设计的目的与折中 存在的问题以及改进这四个部分 背景 目标： 精准复现、定位并理解技术问题的本质、影响范围及业务上下文。 关键活动： 问题复现与场景描述 (Reproduce & Describe): 复现路径： 明确稳定复现问题的具体步骤、输入和环境（开发、测试、生产环境；特定用户/数据）。 异常表现： 清晰描述“不符合预期”的具体行为，包括错误日志、监控指标异常（延迟、错误率、资源使用率）、UI/API 表现等。 预期行为： 明确在同样场景下，系统 应该 表现出什么样的行为。 根因分析 (Root Cause Analysis - RCA): 信息收集： 收集相关日志、Metrics、Traces、Dump 文件、配置信息、代码版本、变更历史。 关联分析： 分析时间线，将问题现象与系统变更、流量波动、依赖服务异常等进行关联。 假设与验证： 提出可能的根因假设，并通过调试、日志分析、实验等手段进行验证或排除。 影响评估 (Impact Assessment): 业务影响： 评估问题对用户、业务流程、收入、SLA/SLO 的具体影响。 技术影响： 评估问题对系统其他模块、数据一致性、安全性的潜在影响。 现状审视 (Review Current State): 审视当前代码库、架构设计、技术文档中与问题相关部分。 了解是否存在已知的类似问题或临时的 Workaround。 产出： 一份详尽的 技术问题分析报告 (Technical Problem Report / RCA Report)，包含复现步骤、根本原因、影响范围和相关证据。 约束条件 目标： 明确解决方案必须遵守的技术边界和需要达成的技术/业务指标。 关键活动： 识别技术约束 (Identify Technical Constraints): 平台/语言/框架： 必须使用的编程语言、框架、操作系统、云平台等。 架构/兼容性： 必须兼容的现有系统架构、API 接口、数据格式、老版本等。 资源限制： CPU、内存、存储、网络带宽、预算等硬性限制。 规范/安全： 必须遵守的编码规范、安全标准、合规要求。 定义技术目标 (Define Technical Goals): 功能性目标： 解决方案需要实现的核心功能。 非功能性目标 (NFRs): 明确性能（延迟、QPS）、可用性 (Availability)、可靠性 (Reliability)、可伸缩性 (Scalability)、可维护性 (Maintainability)、可测试性 (Testability) 等方面的具体指标要求。 明确核心假设 (Identify Technical Assumptions): 方案设计所依赖的底层库行为、第三方服务承诺、网络环境稳定性等假设。 产出： 一份 技术规格与约束清单 (Technical Specifications & Constraints List)，作为设计方案的输入和评判标准。...