同期接到四个演示项目：智慧园区停车系统（SmartPark）、校园班车调度（campus-bus）、通用 IoT 平台（iot-platform）、餐盘识别系统（clean-plate）。限期一周内"看起来能用"。这类项目最容易踩的坑是：在非关键细节上过度完备，结果关键路径没时间打磨。
什么必须真
数据流通和关键交互是演示的生命线。用户点一下按钮，必须有实时反馈。用户看一张报表，数字必须算对。
SmartPark 的核心是可视化——地图展示、停车位实时状态、收费计算。这三个环节缺一不可。地图集成（高德 API）、数据绑定、前端计算逻辑都必须真实运转。相反，权限管理的细分（运营、财务、巡查员各自的权限边界）在演示阶段可以完全省掉，所有用户走同一条权限路径就够了。
campus-bus 的核心是班车轨迹和到达预测。班车坐标实时更新、用户能看到倒计时，这才能说"班车调度系统"。与其花时间做用户认证和学工处接口对接，不如用 mock 数据把轨迹动画做流畅。MSW 库（SmartPark 里用了）可以在开发阶段拦截 HTTP 请求，返回写好的假数据，前端感知不到后端是否存在。
iot-platform 设计文档里提到多租户、RBAC、分布式锁、Kafka 消费端幂等等，这些都是生产级别才需要的。演示阶段关键路径是：设备能连上 → 上报数据 → 看板展示。单租户模式启动（环境变量控制，文档里明确支持），所有权限检查用一个假 admin 令牌搞定，Kafka 改成单 broker 部署，Redis 用单机版。核心的时序数据写入（Micro-Batch 到 MongoDB Time Series Collection）是真的（因为这是展示数据的基础），但"百万设备并发时的背压机制"完全可以不实现。
clean-plate（餐盘识别）的瓶颈在 AI 模型推理。假设已经有了一个能用的识别模型，演示重点是前端能拍照 → 调推理服务 → 展示识别结果。模型的精度、冷启动优化、批推理这些可以后来再优。
共同的一条线是：数据可以是假的（用 mock 返回），但数据流通的路径必须是真的。
什么可以假
并发和容错是演示的盲点。开发环境单机跑，谁会同时登 50 个用户？
SmartPark 不需要考虑"10 万辆车同时更新位置"——演示用几十辆数据刷屏就很炫了。不需要分布式锁保证停车位售出不超卖，单机内存里用个计数器就够。不需要支付系统的幂等设计和对账，演示时支付直接假装成功。
campus-bus 不需要处理"100 班班车同时调度冲突"。没有并发冲突检测，也不需要队列和任务调度系统。轨迹上报和用户查询都走单个实例，简单粗暴。
iot-platform 设计文档里关于"设备状态一致性"的三层保障（心跳 TTL、断连事件、状态修复巡检）在演示版完全可以忽略。直接写 Redis，没有巡检任务，设备掉线了刷新页面重新查就行。Kafka 消费端幂等（messageId 防重）也不需要，反正数据量小。
异常分支更不用说——登录失败、网络超时、服务宕机这些错误处理在演示里往往是 console.error 一行了事，或者弹个提示框就过去了。没人会用 Sentry 做错误追踪，没人会写降级方案。
演示项目的数据一致性、高可用、容错，这些生产级的需求全部可以零实现。
复用的界限
四个项目用的技术栈不完全一样：SmartPark 和 campus-bus 都是 Vue 3，iot-platform 是 React，clean-plate 是什么具体没看。完全共用一套脚手架不现实。
但能复用的是设计令牌和组件库选型。SmartPark 用 Ant Design Vue 4，campus-bus 虽然更简洁但也能接入 Ant Design。iot-platform React 用的是 Ant Design 5。共用 Ant Design 意味着色板、字体、组件 API 是一致的，用户看起来像是"一家人"。
关键是把差异收在业务页面。共同的部分是：
- 登录/权限框架（虽然演示时全部跳过，但代码结构保留）
- 路由和菜单结构
- 数据 API 调用层（axios 或 fetch 封装）
- 表单、表格、弹框这些通用组件
- 色彩、间距、阴影这些设计系统
业务差异放在各自的模块里：地图组件（SmartPark 专属）、时序图表（iot-platform 专属）、图像识别 UI（clean-plate 专属）。
实际效果是：前端架构像一个"半骨架"，部分通用，部分预留接口。新项目接入时快速填充业务逻辑即可。
反思：时间分配的陷阱
一周四个项目，最容易掉的坑：在非关键处投入时间。
比如某个项目花了两天做完整的权限管理系统——细粒度权限点、角色继承、数据权限范围等等。结果发现核心数据展示还没做完。演示时别人只看到"权限菜单很齐全但数据看不到"。这就本末倒置了。
又比如某个项目花时间做"错误处理和重试逻辑"，包括网络超时、服务异常、降级方案。实际演示时网络稳定，这些代码完全用不到，反而增加了调试难度。
正确的姿势是：先把关键路径跑通（最短的从输入到输出的数据链），再看有没有时间加糖。
SmartPark 的时间分配应该是：
- 高德地图集成 + mock 停车位数据（2 天）
- 停车位状态展示和实时更新（1 天）
- 收费计算逻辑（0.5 天）
- UI 打磨和动画效果（1.5 天） 省掉权限、支付对接、后台管理这些，演示版根本用不到。
campus-bus：
- Mock 班车轨迹数据 + 地图展示（1.5 天）
- 轨迹动画和到达倒计时（1.5 天）
- UI 美化和粒子效果（1 天） 省掉用户认证、学工处接口、调度算法优化。
iot-platform：
- 设备 mock 数据和 EMQX 单机部署（1 天）
- 设备列表、状态展示、时序图表（2 天）
- 简单的指令下发模拟（0.5 天）
- 看板美化（0.5 天） 省掉多租户隔离、复杂的 Kafka 消费逻辑、灰度发布、99.9% 可用性这些架构细节。
关键实践
- 明确最少可行演示：在写代码前，列出"演示时必须工作的 3-5 个功能"。其他一切都是可选的。
- 默认 mock 所有后端接口：除非后端已经完成且稳定，否则前端用 mock 数据。这样前后端可以完全解耦开发，演示时换成真实 API 即可。
- 用环境变量控制功能开关：生产级的功能（权限校验、幂等检查、限流）用 feature flag 包裹，演示环境全部关闭。不是删代码，而是不执行。
- 复用而不共享：建立一套通用的组件库和设计系统，但不强制每个项目都用。允许项目选择最适合的技术栈，只要最后看起来协调就行。
- 最后一天留给抛光：前六天完成功能，最后一天专注 UI 细节、动画、错误提示文案。演示的第一印象很重要。
演示项目成功的标志不是架构有多完善、功能有多全面，而是用户第一眼看到"这东西能用"。所有投入都应该指向这一点。
■