上周朋友小陈跳槽，面了家创业公司，聊到一半CTO突然问：“你上一次部署Nginx反向代理是什么时候？能手写个Dockerfile让Vue项目跑在Alpine镜像里吗？”小陈愣了下——他主攻React和Node.js，对运维细节只停留在“npm run deploy”那层。
广度不是拼凑技能清单
很多人以为全栈=前端+后端+数据库+服务器+CI/CD，于是疯狂堆技能树：学完Vue马上啃Spring Boot，刚配好Redis又去翻K8s文档。结果是，简历写着“精通5种语言、熟悉7类中间件”，但被问到“怎么用Redis实现分布式锁避免超卖”，只能含糊说“好像要加过期时间……”
技术广度真正的价值，不在于你会多少工具，而在于你能不能在问题现场快速判断哪块该动、哪块不能碰。比如用户反馈“订单页面加载慢”，有经验的全栈会立刻分三路排查：
— 前端看Network面板查首屏资源体积；
— 后端翻日志看MySQL慢查询；
— 运维视角扫一眼服务器CPU是否被定时任务拖垮。
广度是“连点成线”的能力
真实项目里，问题从不按技术栈边界长。举个例子：
你用Express写了个API，返回JSON给前端，一切正常。某天运营说“商品列表页卡顿严重”，你发现接口响应变慢了3倍。查代码没异常，数据库QPS也平稳。最后发现是CDN缓存策略把POST请求也缓存了——前端调用的是POST /api/search，而CDN默认缓存所有200响应。
这问题横跨前端调用方式、后端HTTP方法语义、CDN配置逻辑三层。没有对各环节的基本理解，光盯代码或光刷日志都绕不出死胡同。
怎么练出有用的广度？
别从“我要学DevOps”开始，从“我今天要上线一个功能”开始：
— 写完React组件，顺手打开Chrome DevTools的Network，看它发了几个请求、每个耗时在哪；
— 后端接口测通后，ssh进测试服务器，用curl -v http://localhost:3000/api/test确认服务真在跑；
— 部署时别只复制粘贴脚本，删掉一行再试试，看报错提示是不是真懂。
真正管用的广度，是知道Webpack打包后index.html里