最稳妥做法是用nginx镜像部署Vue；node+serve仅为开发临时方案，缺乏缓存、压缩、HTTP/2等生产级优化，且单线程易卡顿，不适用于Kubernetes等生产环境。
直接用 nginx 镜像部署 Vue 是最稳妥、最轻量、最符合生产习惯的做法；别用 node + serve，它只是开发临时方案，没做静态资源缓存、Gzip、HTTP/2 优化，还容易因进程模型出问题。
为什么不用 node + serve 部署 Vue？
serve 是 Express 封装的简易服务器，专为本地预览设计。它默认不压缩响应、不设置缓存头、不支持 HTTP/2，且单线程模型在并发稍高时就容易卡住。Kubernetes 里跑它，等于把开发玩具当生产服务用。
-
serve -s不校验publicPath，Vue Router 的history模式会 404（除非加-c配置） - 镜像体积大（
node:lts-alpine约 120MB，nginx:alpine仅 23MB） - 无法复用成熟的 Nginx 配置能力（如反向代理后端、限流、自定义错误页）
nginx 镜像必须配 custom nginx.conf 吗？
不是必须，但强烈建议。默认 nginx:alpine 的配置不兼容 Vue Router 的 history 模式——用户刷新任意路由（如 /user/123）会直接返回 404，因为 Nginx 找不到对应物理文件。
- 必须重写所有非静态资源请求回
/index.html，靠前端路由接管 - 最小可用配置只需覆盖
location /块，加try_files $uri $uri/ /index.html; - 别直接
COPY nginx.conf /etc/nginx/nginx.conf—— 会覆盖全局配置（含 events、http 等），应只覆盖/etc/nginx/conf.d/default.conf
server {
listen 80;
location / {
root /usr/share/nginx/html;
try_files $uri $uri/ /index.html;
}
location /api/ {
proxy_pass http://backend-service:8080/;
}
}Deployment 中 containerPort 和 service port 怎么对齐？
关键不是“对齐”，而是分清三类端口作用：容器监听端口（containerPort）、Service 暴露端口（port）、Node 节点映射端口（nodePort）。Vue 静态服务只用前两个。
PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。
立即学习“前端免费学习笔记（深入）”；
-
containerPort必须和 Nginx 实际监听端口一致（默认 80），否则 readiness probe 会失败 -
port是 Service 内部访问端口，可任意设（如 80 或 8080），但要和targetPort匹配 -
nodePort只在type: NodePort时需要，范围必须是 30000–32767，生产环境建议用Ingress替代
常见错误：containerPort: 8080 却没改 Nginx 配置，结果容器起不来；或 targetPort 写成字符串 "80"（YAML 会转成字符串类型，K8s 要求整数）。
如何验证部署后路由和资源加载是否正常？
别只刷首页看是否出来，重点查三件事：
- 打开浏览器开发者工具 → Network 标签页，刷新页面，确认所有
.js、.css请求状态码是 200，且响应头含Cache-Control: public, max-age=31536000（表示 Nginx 正确设置了长期缓存） - 手动在地址栏输入一个子路由（如
/about）并回车，不点菜单——这是测history模式重写是否生效 - 进 Pod 执行
kubectl exec -it <pod-name> -- ls /usr/share/nginx/html，确认index.html和assets/目录存在且非空
最容易被忽略的是构建阶段的 publicPath 配置：如果 Vue 项目用了相对路径（publicPath: "./"），而你又通过 Ingress 带了子路径（如 example.com/app/），那所有资源请求都会错位——这时得在 vue.config.js 里设 publicPath: "/app/"，且 Nginx 配置里 root 要相应调整。
