Java转全栈，哪些能力必须自己补？一份不带滤镜的清单

Java转全栈，哪些能力必须自己补？一份不带滤镜的清单

先问个问题：如果明天让你一个人从零交付一个带页面的系统，前端后端都自己扛，你卡在第几步？

我自己被问过这个问题。当时我的答案是卡在"npm install 完之后该干什么"。不是不会写代码，是不知道下一步往哪走。后端那套我熟，可一旦把浏览器打开，我就变成了个只会搜报错的人。

这两年我陆续补了一些，最近两个月用飞算JavaAI跑通了两个完整项目。这篇想把一件事说清楚：Java 后端转全栈，到底哪些能力是真的缺的，补到什么程度算够，以及哪些环节工具帮你推到一半就必须自己接手。

不吹工具，也不吹自己。踩过的坑我会写出来。

一、先泼盆冷水：转全栈不是"再学一门语言"

我干 Java 后端五年。刚开始转的时候，我以为难点是 Vue 难不难学。现在看，这个判断错得离谱。

最要命的是最后一条。我年初买了本 Vue 的教程，从响应式原理看到虚拟 DOM，笔记记了三十多页，然后呢？打开编辑器，照样不知道一个后台管理页面从哪个文件开始写。

先跑通，再补细节。 这句话听着像废话，但我用了两个月才真的信。

二、能力地图：你已经有的，和还差的

下面这张表是我给自己做的盘点。左边是 Java 后端本来就该有的底子，右边是转全栈之后还得补的，最后一列是"够用"标准，不是"精通"标准。

看完这张表你会发现一件有意思的事：真正从零开始的只有前端和部署两块，其余都是"在同一层楼上再加一层"。

这个认知对我很重要。它意味着转型的成本没有我想的那么高，但也意味着——前端和部署这两块，没有捷径，必须自己踩一遍。

三、五个维度，各自要补到什么程度

我不打算给"精通"的标准，那玩意儿害人。下面全是"够用"线，以及明确不用学的东西。

1. 前端：够用 = 能改、能接、能跑

要补到：能独立起一个 Vue 3 工程；能看懂并修改别人写的组件；能接接口渲染列表和表单；能配路由和菜单权限；能在浏览器控制台里看懂报错信息。

明确不用补：手写复杂动画、虚拟滚动、Vite 的深度优化、TypeScript 类型体操。这些是我当初瞎学的，一个项目里一次都没用上。

我实际花了不到三周，但那三周是"边做项目边查"，不是"先学完再做"。

2. SQL 与数据建模：工具最容易漏的一块

要补到：能评审表结构；能判断什么字段该加索引、什么时候唯一约束比应用层校验靠谱；能看懂执行计划；知道深分页怎么处理。

为什么要强调这块？因为工具生成的建表语句普遍索引偏少。我做考试系统那次，十四张表里有一半需要我自己补索引和唯一约束。它给的是"能跑"的表，不是"能扛"的表。

-- 我评审表结构时固定会做的三件事
-- 1. 看这张表现在有哪些索引，别只看主键
SHOW INDEX FROM exam_answer;

-- 2. 拿一条真实查询看执行计划，重点看 type 和 rows
EXPLAIN SELECT id, question_id, score
FROM exam_answer
WHERE record_id = 123456 AND question_id IN (1001, 1002, 1003);

-- 3. 确认唯一约束有没有真的建上，这是幂等的最后一道防线
SHOW CREATE TABLE exam_answer\G

3. 部署：我以为可以拖到最后，结果上线那天手忙脚乱

要补到：一台干净机器上，能把后端 jar 和前端 dist 都跑起来；会用 nginx 做反向代理；知道日志在哪、怎么看；出问题时能回滚到上一个版本。

我第一次上线是在客户机器上现学现配，nginx 配置改了六遍，最后发现是 client_max_body_size 默认 1M 把上传请求拦了。当时场面很难看。

最小可用的一份配置长这样，能省掉你第一次上线的尴尬：

# nginx.conf 关键片段（配合 docker 挂载使用）
server {
    listen       80;
    server_name  localhost;
    client_max_body_size 20m;   # 默认 1M，上传文件必踩

    location / {
        root   /usr/share/nginx/html;   # 前端 dist
        try_files $uri $uri/ /index.html;  # 前端路由刷新 404 靠这行
    }

    location /api/ {
        proxy_pass http://exam-backend:8080/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_read_timeout 60s;
    }
}

4. 排错：最值钱的一项，也是最没法教的一项

要补到：十分钟内判断出问题在哪一层。前端的数据就不对？接口返回就不对？还是后端查库查错了？

我给自己定了一套固定动作，每次报错按顺序走，不走捷径：

# 1. 前端有没有真的发出请求？看 Network 面板，别先猜后端
#    命令行先用 curl 绕开浏览器，确认接口本身通不通
curl -s -X POST http://localhost:8080/api/exam/submit \
  -H "Content-Type: application/json" \
  -d '{"recordId":123}' | head -c 500

# 2. 后端收到了吗？看实时日志
docker logs -f exam-backend --tail 200

# 3. 数据库里到底是什么状态？别信接口返回的，直接查
docker exec -it exam-mysql mysql -uroot -p -e \
  "SELECT id, status, submit_time FROM exam.exam_record WHERE id=123;"

# 4. 慢在哪？开慢查询日志，别凭感觉优化
docker exec -it exam-mysql mysql -uroot -p -e \
  "SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1;"

这四步做完，八成的问题都能定位。我以前最大的毛病是一上来就改后端代码，结果有三次问题其实在前端传参。

5. 产品思维：最虚，但决定你能不能接到活

要补到：能在需求阶段问出那几个关键问题；能主动砍需求；能分辨"必须有"和"最好有"。

判断标准很实在：客户说完一句话需求，你能不能反问出三个让他愣一下的问题。做考试系统那次，我砍掉了摄像头监考，两周才收得了尾。砍需求的能力，比写需求的能力重要。

下面是五个维度的"够用标准"汇总，和我当初判断错的地方：

四、四个功能模块分别能把你推到哪一步

这是我最想说清楚的部分。飞算JavaAI 的 /需求分析、/前后端设计、/前端开发、/后端开发 这四个指令，每一个都有明确的"能力边界"。知道它在哪停，比知道它能做什么更重要。

一句话总结：它把你从 0 推到 0.7，剩下的 0.3 全是有业务上下文的部分。

这 0.3 恰恰是全栈工程师真正的价值所在。我做考试系统时，后端生成了大概一万一千行代码，但我自己写和改的部分，几乎全集中在上面那张表的最后一列。

还有个细节得提醒：这四个模块是串联的，上游文档不全，下游就会卡住。我在 /前后端设计 时忘了要前端设计文档，后面 /前端开发 直接跑不动，只能回去补跑一轮。这个坑我踩了两次，第二次是在明知道的情况下踩的。

五、一份可执行的学习顺序

按优先级排，不按难度排。这里的顺序是我踩完坑之后重排的，跟我实际走过的顺序不一样。

为什么把部署排第一？因为它是唯一一个"学完立刻消除恐惧"的项目。 你把服务部署成功一次，后面所有的学习都会带着"反正我能跑起来"的底气。我把它放到最后，结果第一次上线狼狈得不行。

为什么把排错排第四？因为它需要前面积累。你连请求从哪发出去都不知道，谈不上定位。

产品思维没有终点，它贯穿在所有环节里，越早有意识地练越好。

六、我走过的弯路，和当时的错误判断

弯路一：先啃两个月前端理论，一个项目没跑通。 顺序反了。正确做法是第一天就起一个能访问的页面，缺什么补什么。

弯路二：把生成的代码当标准答案，不敢改。 早期我几乎原样用，直到考试系统那次发现交卷接口没做幂等——学员连点两次就会写两份作答。吓得我把所有写接口重查了一遍。工具给的是起点，不是终点。

弯路三：跳过需求阶段直接写代码。 返工最狠的一次就是这个。幸好那次变更发生在第 3 天，只有文档，改起来半天；要是发生在代码写完以后，至少三天。

弯路四：忽视部署，第一次上线手忙脚乱。 前面说过了，不重复。

弯路五：想一次做到满分。 我做第一个项目的时候，纠结列表页的样式纠结了两天。后来发现客户根本不看样式，只看能不能导出成绩。交付比完美重要，这句话我到现在还在提醒自己。

七、写在最后

这两年补下来，我最真实的感受是：转全栈难的不是技术栈变宽了，而是你得开始对"一个完整的东西"负责。以前我只对接口负责，接口返回对了我的活就干完了。现在从需求到上线到线上出问题，全在你身上。

工具确实帮了大忙，它把我最怕的那一步——从空白目录开始——变成了几分钟的事。但它一次都没有帮我在凌晨两点定位过线上问题，也没有帮我跟客户说过"这个功能这版不做"。

说句扎心的：它替你省下的是敲键盘的时间，省不下的是你该承担的判断。而决定你能走多远的，从来是后者。