技术⽅案本质上需要回答两个问题：

• 其⼀，为什么该⽅案可⾏？
• 其⼆，在已有资源限制下，为什么该⽅案是最优的？

为了回答第⼀个问题，我们需要在技术⽅案⾥补充架构图、接⼝设计和时间⼈⼒估算。

⽽要回答第⼆个问题，需要我们在关键点或争议处提供⼆到三种⽅案，并给出建议⽅案，这样才有说服⼒。

通常情况下，我们会花费很多的时间准备第⼀个问题，⽽忽略第⼆个问题。
其实，回答好第⼆个问题很重要，⼤型项⽬的设计已经复杂到没⼈能够⼀次就想到最佳⽅案，⼀个仅仅“可⾏”的⽅案，可能会给系统增加额外的复杂性。

项目技术方案模板

背景

讲清楚what+why，介绍项⽬的背景、相关系统的现状以及相关名词定义。

着重说明项⽬以下问题：

必要性（为什么要做）

⻛险（不做这个事情有哪些影响）

⽬标

要达成的效果，最好是与问题对应。

如果是产品的需求，这⾥直接贴需求对应的⽬标

业务需求是什么？项⽬产出是什么？衡量指标是什么？

整体设计

⼏个部分，分别是⼲什么的，系统的整体流程图和系统的分层架构图

详细设计

⽅案部分，重点讨论：How，怎么做。

如果是概览的⽅案，则需要描述清楚

宏观的架构，主要是模块的关系（组织⽅式）

模块的定义，定位、职责、边界、输⼊输出

对于技术中出现的⼀些具体的技术难点，则需要描述清楚怎么做的。

1、业务流程

业务流程的流程图，不同⻆⾊不同阶段的处理过程，以及各种分⽀情况的条件及处理逻辑。要覆盖

所有流程分⽀，不重不漏。

2、模型/数据库设计

表结构设计，包含：ER图、建表语句

3、关键逻辑/算法

业务流程图中 系统最关键逻辑的具体说明，重点说清楚本系统最关键部分的处理逻辑

4、数据产出逻辑

从原始数据 到 最终结果 过程中的关键计算逻辑说明，包括该逻辑在系统中的的应⽤场景，及具体

逻辑实现等。关键数据指标（需要⾃测和部分QA测试时验证正确性）

5、定时任务

定时任务的作⽤，时间选择，处理逻辑，是否需要失败重试等。数据重跑⽅案（重跑⽅案需要保证幂等性）

6、系统依赖

对上游系统或第三⽅系统的服务依赖，说明具体的依赖场景，围绕该依赖的设计思路等。

接⼝⽂档

涉及到的新增和修改的接⼝⽂档，可以附上⽂档链接6、稳定性保障系统相关的监控，降级，回滚，业务灰度⽅案等措施。

稳定性保障

系统相关的监控，降级，回滚，业务灰度⽅案等措施。

⻛险点

如有相关⻛险点，可以记下来。包括思考点，结论，备注等信息。

项⽬计划

精确到天的时间安排和⼈员分⼯，有明确的检查点。