方案设计

个人觉得前端的方案设计只是在需求相对复杂且稳定的情况下才需要做，否则会适得其反，增加额外的工作量，并且需求经常变化的话也没啥参考意义。做方案设计其实需要有一定的大局观，要求你在短时间内根据以往的经验和调研情况来综合判断需求的可行性和工作量，虽然这并不能 100% 评估所有潜在的风险和问题, 但能在相当程度上减少这类风险

一份好的方案设计文档，会有以下几点优势：

给足开发信心（需求可行性）
提供开发指导，便于执行
提高协作效率
提高专业度（针对上下游）

需求分析

贴上需求文档链接

如果还不是很清楚，可以在这里补充描述。这是一个项目最重要的一步，只有明确需求，才能做好下面的每一步

除此之外还可以贴上

原型链接
UI 稿

交互流程（可选）

组件或模块之间的交互较多，可以进一步补充下交互流程图

技术调研（可选）

需求在技术实现上存在不确定的点，可以从以下几个方面考虑：

新技术，社区不成熟。有一定风险，需要权衡利弊
想做某个功能但不确定能否实现。可以跑一个 demo 验证
对某个框架或库有多个方案，不确定选择哪个

技术选型

列出项目所依赖的顶部技术栈，从以下几点考虑：

终端类型

pc web、移动端、ios、安卓、是否跨端

页面渲染模式

重视 seo 可以选择 SSR、静态应用
重交互选择 SPA
活动页或者 h5，页面比较零散选择 MPA

更多渲染模式可以参考这篇 https://mp.weixin.qq.com/s/XEUDiIQcm4BnZ42adb9IEg

团队资源

方案涉及的技术栈应尽可能匹配团队技术栈，但不用精确匹配
如果需要学习新技术，需要判断是否能预留足够的时间

环境兼容性

考虑浏览器或者 node 环境中一些 api 的兼容性，可能需要针对性做 polyfill

编码规范（可选）

按照技术选型的情况来决定是否需要额外定义一些编码规范。一般情况下沿用前端统一的代码和项目规范即可

项目结构（可选）

如果是新项目，有必要罗列一下项目的结构，减少多人协作的沟通成本

具体实现

具体功能的实现，主要罗列一些关键功能或难点的实现

关键枚举

可以用 typescript 的 enum 定义，如果涉及状态流转最好能给出流程图或时序图

功能 A

功能 B

接口定义（可选）

如果是后端主导，一般贴个链接在这里就可以了前端主导的话，需要和后端确认数据格式是否合理

排期

开发人员、任务细分、deadline、备注、buffer

需求分析​

交互流程（可选）​

技术调研（可选）​

技术选型​

终端类型​

页面渲染模式​

团队资源​

环境兼容性​

编码规范（可选）​

项目结构（可选）​

具体实现​

关键枚举​

功能 A​

功能 B​

接口定义（可选）​

排期​

相关文档​