智慧社区
覆盖充电、门禁、消防与社区服务的后台和小程序系统。
先明确项目为何存在。
从业务目标进入技术问题，让后续架构选择拥有可判断的上下文。
概览
社区管理项目包含智慧充电、智慧门禁、智慧消防和社区服务系统，覆盖后台管理、H5 与小程序等终端。
问题
充电、门禁和消防多端复制列表、地图与支付组件后各自修改，同一交互存在多套实现，需求变更容易遗漏。
真正需要被拆解的约束。
- 01
同时交付后台、H5 与小程序等多种终端。
- 02
复用列表、地图和支付等高频业务组件。
- 03
持续响应需求更替并完成提审、发布和维护。
让数据、状态与交付边界可解释。
以共享业务组件和统一状态流程支撑管理后台、H5 与小程序，再通过终端适配层处理地图、支付和发布差异。
- 01社区业务域
覆盖智慧充电、门禁、消防与社区服务。
- 02共享组件与流程
复用列表、地图、支付状态和回调对账能力。
- 03终端适配
使用 Vue 与 uni-app 适配后台、H5 和小程序。
- 04发布维护
统一代码管理，并分别完成提审、发布与线上维护。
把工程决策和交付结果放在一起验证。
- 01
抽取公共组件库，让业务页面通过配置组合通用能力。
- 02
将支付状态轮询与回调对账收敛到统一模块。
- 03
使用 uni-app 承载 H5 与小程序端，并统一 Git 代码管理。
- 01
交付智慧充电、智慧门禁、智慧消防和社区服务系统。
- 02
覆盖后台管理、H5 与小程序端。
- 03
减少多端公共交互的重复实现和维护遗漏。
性能首先是一组工程约束。
只记录项目中真实采用的策略，不用无法核验的数字替代判断。
优化目标多端重复实现造成的交付与维护开销。
- 01
抽取高频业务组件，以配置组合替代多份页面复制。
- 02
统一支付轮询和回调对账，减少各终端重复请求逻辑。
- 03
通过 uni-app 共用 H5 与小程序业务代码，缩小终端差异面。
沉淀可以迁移到下一次决策的经验。
跨端复用应优先沉淀稳定的业务流程，而不是强行统一所有界面细节。
反思 01
公共能力必须拥有清晰的配置接口，否则组件库容易演变成新的耦合点。
反思 02
从技术栈回到可验证的能力。
技术栈
关联能力