deploy是什么东西
✔ 端口冲突解决（3001）
✔ 服务可启动（next / node OK）
✔ systemd 能接管（已验证）
✔ deploy 开始接入 runtime（现在这步）
这里面其实已经涉及一整套后端/运维/部署/工程化知识了。你不是只遇到一个 bug，而是把一个真实服务从“能跑”推进到“可部署、可托管、可恢复”的阶段。
你这段里涉及的计算机知识点
1. 构建 Build
Creating an optimized production build ... 属于构建阶段。
意思是把源码变成生产环境能运行的产物。对 Next.js 来说，它会做：
源码
↓
编译 TypeScript / JavaScript
↓
打包依赖
↓
生成 .next 产物
↓
优化页面和路由所以它慢是正常的。它不是“卡”，而是在编译和优化。
2. 部署 Deploy
部署不是单纯“上传代码”。
真正的部署流程一般是：
打包源码
↓
上传到服务器
↓
安装依赖
↓
构建项目
↓
同步到运行目录
↓
重启服务
↓
健康检查你现在就在打通这条链。
3. 运行态 Runtime
源码能 build 成功，不代表服务已经在线。
运行态关心的是：
服务有没有启动
端口有没有监听
进程有没有活着
访问有没有响应也就是：
ps aux
curl http://localhost:端口
systemctl status 服务名这些都是在看 runtime。
4. systemd 服务托管
systemd 是 Linux 上管理服务的系统。
你手动跑：
pnpm start只是临时运行。
用 systemd 后变成：
系统负责启动服务
系统负责重启服务
系统负责记录状态
系统负责开机自启这就是从“手动跑”变成“系统托管”。
5. unit 文件
这个：
[Service]
ExecStart=...
Restart=always就是 systemd 的服务描述文件。
它告诉 Linux：
这个服务叫什么
在哪个目录运行
用什么命令启动
挂了要不要重启没有 unit 文件，systemd 根本不知道 atramenti-console.service 是谁。
6. 端口冲突
你之前遇到的：
EADDRINUSE: address already in use :::3000意思是：
3000 端口已经被别的程序占了后来查出来是：
aiclient2api Docker 容器占了 3000所以把 console-web 改到 3001 是正确的。
7. Docker 端口映射
你看到的：
docker-proxy 占用 3000说明 Docker 容器把宿主机的 3000 端口映射给了容器。
大概是：
服务器:3000 → 容器:3000所以别的程序就不能再用服务器的 3000。
8. pnpm workspace
你之前的核心坑是：
packages:
- "."这导致 apps/console-web 没被纳入 workspace。
正确应该类似：
packages:
- "."
- "apps/*"否则 pnpm 不知道 apps/console-web 是项目成员，next 就不会正确安装。
9. node_modules 和软链
你之前还碰到：
runtimeRoot/node_modules
srcRoot/node_modules
apps/console-web/node_modules这就是 Node 项目的依赖目录问题。
pnpm 的依赖结构比 npm 复杂，乱软链很容易让程序找不到 .bin/next。
10. 返回码 Exit Code
Linux 命令执行完会返回一个数字：
0 = 成功
非0 = 失败比如：
exit code 5
exit code 1你现在的问题就是 deploy 脚本太依赖返回码，一旦某一步非0，就认为全失败。
11. set -e
很多 shell 脚本会写：
set -e意思是：
只要任何一行失败，整个脚本立刻退出它适合严格脚本，但部署时如果不处理好，就会因为一个无关紧要的小失败导致整个 deploy 失败。
12. || true
这个：
systemctl --user enable 服务 || true意思是：
即使命令失败，也不要中断整个脚本适合用于“不应该决定部署成败”的步骤。
但注意，不能滥用。真正关键的检查要放到后面，比如：
systemctl --user is-active 服务13. 健康检查 Health Check
真正判断服务是否成功，不应该只看：
命令有没有返回0而应该看：
curl http://localhost:5101
systemctl --user is-active atramenti-console.service这叫健康检查。
14. 前台进程和后台服务
next start 是前台进程：
启动后一直运行，不会自动退出如果部署脚本直接等它结束，就会像“卡住”。
正确方式是交给：
systemd / pm2 / docker这种服务管理器。
15. CI / 非交互执行
AI 执行脚本时最怕命令问：
Proceed? (Y/n)因为没人输入，就会卡住。
所以部署脚本要使用：
CI=true
--force
--yes这叫非交互执行。
你这次实际学到的是哪一类知识？
不是单个知识点，而是这条完整链路：
前端项目构建
→ Node.js 依赖管理
→ Linux 服务器目录管理
→ 端口管理
→ Docker 容器冲突
→ systemd 服务托管
→ shell 脚本
→ 部署流水线
→ 健康检查一句话：
你现在接触的是“后端部署 + 运维工程 + DevOps”的核心入门内容。最简单的理解
你最开始只是想：
让项目跑起来但真实工程里“跑起来”分三层：
1. 能手动跑
2. 能部署跑
3. 能被系统长期托管地跑你现在已经从第 1 层走到第 3 层了。
