怎么避免自己变成只会写接口的人？

1、做需求时，多想多问“这个需求在整个系统里是怎么流动的？”

• 请求怎么来，为什么这么设计，数据库为什么这么设计，数据为什么这么存？为什么拆服务？为什么要这样设计缓存

2、主动理解“系统边界”，比如系统之间如何协作，比如模块是怎么交互的？多花一些系统图，进行理解

• 请求流向->服务关系->数据流->缓存层->网关->MQ

3、多看线上真实问题

• 处理真实复杂性、比如Redis击穿、数据不一致、死锁、慢SQL、服务雪崩、并发问题、MQ重复消费这些是怎么解决的
• 参与：故障分析、线上问题、性能优化、监控

4、别只学框架，要学“为什么？“

• 这个东西解决什么问题？Redis为什么快？MQ为什么存在？微服务为什么复杂？为什么最终一致性？形成架构思维

5、做“自己的系统项目”，把握整体的流程

• 只有一个完整系统，才会理解为什么重要和需要

6、不要只做“功能实现者”，要学会理解“业务”

• 技术最终是在服务业务。系统设计，本质上不是“技术最优”，而是：业务、成本、性能、时间”的平衡

7、学会关注“系统的代价”

• 架构从来不是越高级越好，而是当前阶段最好
• 成本是多少？运维复杂度？学习成本？排障难度？扩展性？团队能不能驾驭？

8、学会“观察复杂性从哪里产生”？

• 看到一个复杂系统，不要先想：怎么这么乱？而是想：“它为什么会演化成现在这样？”

9、学会阅读“真实工程”

• 开源项目源码、公司线上项目、故障复盘、技术博客、GitHub issue、架构演进文章

• “为什么这么改”

10、不要把“技术成长”理解成“知识收集”

• 真正的成长来自：理解 -> 动手 -> 出问题 -> 调试 -> 重构 -> 复盘

• 一定要持续输出。比如：小项目、博客、技术总结、系统图、Demo

11、工程师真正的成长，是开始理解“权衡”

• 没有“最好的方案”，只有“时间、人力、成本、性能、风险”，之间的“权衡”

• 工程不是数学题，而是在有限资源里的持续平衡。

12、尽量进入“真实复杂系统”环境。

• 关注看有没有：1）真线上环境2）真用户3）真问题4）真压力5）真协作
• 真实世界的复杂性，才是工程师成长最快的老师。

最后需要记住，当遇到项目的时候，应该反复问自己：1、系统怎么运作？瓶颈在哪里？为什么这样设计？未来怎么演化。