小张刚入职一家创业公司，被安排参与一个新项目。老板说：‘你先跟着做开发，顺便学学架构设计。’他点点头，心里却嘀咕：不就是写代码吗？画几张图、配几个服务，和敲代码有啥区别？
画图不等于设计，写代码也不等于开发全貌
很多人把‘架构设计’理解成画UML图、选Spring Cloud还是Dubbo、决定用MySQL还是MongoDB——这些确实是架构工作的一部分，但只是表层动作。真正的架构设计，是在业务还没上线前，就预判出：用户量涨10倍时API会不会挂？支付回调失败后怎么保证不丢单？日志分散在5台机器上，出了问题怎么快速定位？
而开发，是把确定的需求，转化成可运行、可测试、可交付的代码。比如实现一个订单导出功能，开发关注的是：Excel生成是否正确、文件名带不带时间戳、导出超时有没有提示、并发下载会不会卡死。
一个真实场景对比
假设要做一个社区发帖功能：
架构设计会问：
– 发帖峰值每秒300次，数据库扛得住吗？要不要加Redis缓存热帖？
– 图片上传走CDN还是自建OSS？如果CDN回源失败，前端有没有降级策略？
– 用户举报帖子后，内容下架是实时删除，还是逻辑标记+异步清理？为什么？
开发则聚焦：
– POST /api/posts 接口校验标题长度、过滤敏感词、保存到MySQL；
– 上传图片调用OSS SDK，返回URL存进数据库；
– 写单元测试，覆盖空标题、超长内容、重复提交等边界情况。
职责错位，项目最容易翻车
常见误区是让资深开发直接‘兼做架构’，结果系统上线三个月就出现慢SQL拖垮整个库——因为没人提前规划分库分表时机；或者微服务拆得满天飞，服务间调用链长达8层，一出问题查半天。这不是开发能力差，而是角色任务混了。
架构设计像盖楼前的结构工程师：算风载、定梁柱尺寸、留好水电通道；开发则是施工队：按图砌砖、布线、装门窗。图纸错了，砖砌得再齐也没用；图纸对了，施工马虎，楼照样漏水。
两者需要互相听得懂对方的话
好架构不是纸上谈兵。它必须能落地：不能要求开发硬上Kafka却连重试机制都没想好；也不能为了赶进度，把所有模块塞进一个Spring Boot Jar里，等流量上来再推倒重来。
一线开发者如果能多问一句‘这个接口未来要支撑多少QPS？’，架构师如果愿意蹲点看两小时开发联调报错日志，很多坑，其实早就能绕开。