这一年做停车业务，我开始更像一个解决问题的人
这一年做智慧停车和周边生态项目，最大的感受不是“业务更复杂了”，而是我越来越能体会到，前端真正的价值，很多时候不是把页面写出来，而是把那些影响业务闭环的问题一个个接住。
有些问题是体验层面的，有些是工程层面的，有些甚至是偏系统设计的。也正是这些事，让我慢慢从“完成功能的人”，变成了“更像一个解决问题的人”。
业务一复杂，前端就不只是写页面了
做停车相关业务，表面看是缴费、订单、地图、核销、追缴这些模块，但真正做进去之后，会发现链路很长，场景很碎，很多细节都和真实世界强绑定。
比如倒计时不是简单 setInterval 一下就行，因为客户端时间可能不准；移动端问题也不是浏览器里复现一下就能解决，因为真机环境常常更像黑盒；还有一些看起来只是“弹个提示”的地方，到了跨端项目里也会遇到上下文受限的问题。
这些事情单看都不算大，但一旦放进真实业务里，它们就会直接影响用户是否能完成操作，或者团队能不能快速定位问题。
我开始更在意“方案能不能落地”
这段时间我做过几件自己还挺有感触的事情。
一个是倒计时方案。以前写倒计时，更多是站在前端视角思考刷新频率和展示格式。后来到了支付、核销这些场景，才发现真正关键的是“时间基准”是不是可信。所以最后我更倾向于服务端时间做基准，前端只负责差值计算和展示，这样稳定很多。
一个是 Global Toast。这个需求看起来很小，但在 UniApp 里，要在路由守卫、请求封装这些非组件上下文里统一唤起提示，并没有那么直接。后来通过状态管理和统一注入的思路把它打通之后，很多基础交互才真正顺了起来。
还有一个是 PageSpy 远程调试。这个对我触动挺大，因为它解决的不是“开发写代码不方便”，而是线上和测试环境的问题很难复现。移动端一旦成了黑盒，很多 Bug 都只能靠猜。把这套能力接进来之后，排查效率确实提升了很多。
我也越来越理解“性能优化”不是一个点子
以前我对性能优化的理解，更多是懒加载、压缩、分包这些手段。后来项目做多了，我越来越觉得，性能优化更像是一套取舍方法。
什么时候该先减请求，什么时候该先拆包，什么时候该优先解决用户感知，什么时候该从接口聚合和数据结构下手，这些都不是背几个方案就够的。
尤其是偏业务型项目，很多性能问题最终都要回到链路本身去看。前端能做的当然很多，但真正有效的优化，往往是把前后端、静态资源、交互反馈放在一起综合考虑。
这一年的变化，可能不是技术名词，而是判断力
回头看，这一年我学到的东西当然不少，但如果只让我选一个变化，我会选“判断力”。
我开始更清楚：
- 什么问题值得做成通用方案
- 什么问题应该先追求稳定，再追求优雅
- 什么问题不能只站在前端自己的视角看
- 什么方案在文档里很好看，但在业务里未必最合适
这种变化对我来说挺重要的。因为它意味着我不再只是拿着现成答案套问题，而是在真实场景里慢慢形成自己的取舍逻辑。
这可能也是我最近最想继续积累的能力。