用 nginx 镜像跑 HTML 站点是最稳的选择，因其轻量（alpine 版仅约 5MB）、安全、可复现；而 http-server 等开发工具缺乏生产级特性（如 gzip、缓存头、try_files）、权限松散、无守护机制，且镜像体积大、挂载不可靠，故生产环境禁用。
用 nginx 镜像跑 HTML 站点是最稳的选择，不碰 Node、不写服务逻辑，只要文件放对位置、路径配准、权限给够，就能上线。其他方式（比如 http-server 或自己装 Ubuntu + Nginx）要么不安全、要么体积大、要么不可复现，生产环境基本不用。
为什么不能直接用 http-server 或 live-server 跑 Docker？
它们是开发时的临时工具，不是为生产设计的：
-
http-server默认没开 gzip、没设缓存头、不支持try_files回退——刷新子路由（如/about）直接 404 - 权限模型松散，容易暴露源码或触发目录遍历（比如访问
../package.json） - 进程无守护机制，OOM 或崩溃后不会自动重启
- 镜像体积动辄 200MB+（含 Node、npm、devDependencies），而
nginx:alpine仅约 5MB
docker run -v 挂载方式只适合本地调试
命令看着简单，但线上不能用：
- 容器重启后挂载点可能失效（尤其在 Kubernetes 中，
hostPath常被策略禁用） - 必须确保本地
dist/目录下有index.html，且在根级（不是dist/src/index.html） - Linux/macOS 下若宿主机文件无其他用户读权限（
ls -l dist显示rw-------），容器内 Nginx 会报 403 - 挂载路径必须用绝对路径或
$(pwd)，相对路径在 CI/CD 流水线里极易失效 - 加
:ro是硬性要求——防止容器内进程意外覆盖你本地构建产物
Dockerfile 构建才是生产唯一可靠路径
把 HTML 文件真正打进镜像，才能保证环境一致、可复现、可打版本标签：
立即学习“前端免费学习笔记（深入）”；
-
Dockerfile示例（注意路径和分号）：FROM nginx:1.25-alpine RUN rm /etc/nginx/conf.d/default.conf COPY nginx.conf /etc/nginx/conf.d/ COPY dist/ /usr/share/nginx/html/
-
nginx.conf至少包含三行关键配置：-
root /usr/share/nginx/html;（别漏分号） -
try_files $uri $uri/ /index.html;（Vue/React history 模式必需） -
location ~* \.(js|css|png|jpg)$ { expires 1y; }（静态资源强缓存）
-
- 构建命令：
docker build -t my-site:v1 .，运行：docker run -d -p 8080:80 --name site my-site:v1 - 别在镜像里留任何 dev 工具（
vim、curl、bash都非必需），减小攻击面
白屏、404、403 这些错误背后的真实原因
不是“配置不对”，而是几个具体点卡住了：
- 浏览器 Network 标签页看到
/js/app.js 404？检查 HTML 里<script src=""/my-app/js/app.js">的路径前缀是否和实际部署路径匹配；再确认构建产物真在dist/js/app.js，而不是dist/my-app/js/app.js - 打开页面是 403？先
ls -l dist看权限，再进容器docker exec -it site ls -l /usr/share/nginx/html确认文件是否真复制进去了 - 刷新
/about白屏？说明try_files没生效，检查nginx.conf是否加载成功（docker exec site nginx -t）、是否写在location /块里、有没有拼错变量名（比如写成$uris）
最常被忽略的是：构建时 COPY 的源路径是否真的存在，以及 nginx.conf 里 root 指向的路径是否和 COPY 目标完全一致——差一个斜杠、多一层目录，就全挂了。
