摘要
很多开发者在接到需求时，第一反应是「能不能做」。本文分享一位前端在项目收尾期独立负责多套终端与后台系统的真实经历：设备运行日志迁移、ECharts 点位分析、遗留系统里实现带参数跳转、三班制切换凌晨排障、浏览器升级导致的文本截断与日期组件遮挡等。并延伸到 HIS 迭代、Vben Admin 从 0 到 1 交付医保与公共基础管理系统。核心观点很简单：少空转，多验证；失败成本远低于不敢动手。
前言：一种比「技术栈」更重要的开发习惯
入行久了，我发现一个共性问题：
遇到需求或技术猜想时，容易陷在「能不能实现」「可不可以」里反复纠结。
我的做法恰恰相反：先动手，再验证，再查资料。 失败了顶多多花点时间，但每一次尝试都会沉淀成下一次的捷径。
下面按时间线，把几家公司的关键项目拆开讲——重点是问题怎么来的、怎么定位的、我学到了什么，而不是堆项目名。
一、项目收尾：前端只剩我一个时，系统在发生什么
现场配置
项目收尾阶段，前端基本撤回，现场留下：
| 角色 | 人数 |
|---|---|
| 后端 | 1 |
| 前端（我） | 1 |
| 需求 | 1 |
我负责前端收尾：保证稳定 + 完成剩余功能，其中包括设备运行日志从 A 项目迁移到 B 项目。
同时维护的现场形态：
- 3 个大屏
- 1 个 TV 屏
- 1 个终端
- 1 套大规模后台管理系统
这不是纯页面开发，而是交付型前端：稳定性、兼容性和业务完整性都要扛。
二、四个典型难题（含思路，不只结果）
1. 设备运行日志：ECharts + 点位分析
需求：页面上方 ECharts 图表，且每个数据点可下钻/分析，交互要可用。
难点：
- 迁移不等于复制组件，数据结构和接口往往不一致
- 图表与明细列表的联动状态要一致
- 大屏场景下还要考虑分辨率与性能
做法摘要：
- 先对齐旧项目与新项目的字段与刷新频率
- 图表
click/tooltip与明细区用同一套dataIndex或业务主键关联 - 大屏单独过一遍字号、间距和 legend 遮挡
收获：可视化需求要同时满足「好看」和「可分析」，接口设计和前端状态要一起想。
2. 带参数的系统地址：在遗留代码里改需求
背景：原系统能配置外部地址，但不支持带参跳转，用户要求可传参。
约束：不能影响其他功能——典型遗留系统改造场景。
过程：花约一周阅读前辈代码，理清配置入口、路由/iframe 加载链路和权限校验，再在最小改动面落地。
可复用经验：
1. 画调用链（谁读配置 → 谁渲染 → 谁跳转）
2. 找「唯一真相」的配置结构，避免多处硬编码
3. 用开关或兼容分支，保证老地址仍可用
3. 三班制切换：凌晨三点的联调排障
场景：年终客户要求切换为「大三班」模式，切换后系统异常。
特点：业务规则变更 + 历史数据 + 多角色同时使用，问题往往不是单点 bug。
协作：前后端 + 需求一起排查，凌晨 3 点定位并恢复。
收获：
- 生产问题要保留时间线（何时改配置、何时发布、何时 first error）
- 先恢复可用，再复盘根因
- 「排班类」需求提前做边界用例（跨天、换班、节假日）
4. 浏览器升级：看板文字变 ... + 日期组件被挡一半
现象 A：看板文本全部显示为 ...
排查：按浏览器版本对比 → 定位到字体/行高/text-overflow 或 flex 子项收缩问题
现象 B：全局日期组件日志区域被遮挡、显示不全
排查：往往是 overflow、z-index、弹层容器高度在特定分辨率下叠加
收获：兼容性问题的捷径是版本矩阵 + 最小复现页面，不要在大屏上盲改。
三、能力边界被继续拉大：运维、出差、行业项目
后续经历进一步把「前端」从页面层拉到系统层：
| 阶段 | 内容 | 能力侧重 |
|---|---|---|
| 码上运维 | 线上问题与需求变更 | 沟通、排期、快速修复 |
| 合肥 CPS 改造 | 出差配合现场二次升级 | 协作、现场交付 |
| 云南中烟调度 | 调度类业务系统 | 行业业务理解 |
和后端「争论需求」在当时很累，现在看是在练需求边界和接口契约。
四、第二家公司：七个月里的 0-1 与迭代
换公司后七个月，完成：
- HIS 系统迭代升级
- 基于 Vben Admin 从 0 到 1：公共基础管理系统
- 基于 Vben Admin 从 0 到 1：医保管理系统
为什么七个月就离开？
个人选择：减少频繁出差，希望地理和节奏更稳定。与能力无关。
技术侧可写进简历的亮点：
- 管理后台脚手架、权限、菜单、字典等通用模块落地
- 医保业务模块在统一基座上的扩展
- 老系统迭代中的兼容与迁移策略
五、给同行的一点建议（尤其是容易「想太多」的人）
- 把「能不能做」改成「最小验证要多久」——半天能写 demo 的，别纠结三天
- 遗留系统先画链路再改代码——带参地址这类需求尤其如此
- 大屏/看板单独做兼容清单——浏览器、分辨率、字体
- 排障留时间线——三班制这类问题没有 timeline 很难查
- 框架从 0 到 1 时先固化「基座能力」——权限、配置、日志，再铺业务
结语
快三十、换工作、女性开发者——市场环境确实会更苛刻一些。
但项目收尾能稳住多套终端、遗留系统能改出兼容方案、凌晨能把生产拉回来、框架能从 0 交付两个系统——这些是可验证的硬经验。
别问能不能做。先动手，失败了也不亏。
如果你也在做收尾、迁移、大屏或医疗后台，欢迎评论区交流具体场景的踩坑细节。
