做开发的都知道，本地写完代码推到仓库，自动打包部署到测试机，第二天产品点开链接一看——404。查了一圈才发现，服务是起来了，但端口没对外暴露，外网根本访问不了。这种情况在持续集成部署流程里太常见了，尤其是涉及容器化部署时，端口映射这一步一旦忽略，整个流程就卡住了。
CI/CD 流程中为什么需要端口映射
比如你用 GitLab CI 跑流水线，构建完 Docker 镜像后自动启动容器。默认情况下，容器内部的服务可能跑在 3000 或 8080 端口，但宿主机并没有把对应端口映射出来。这时候就算容器运行正常，你也无法通过 服务器IP:端口 访问页面。
举个实际场景：你在公司搭了个自动化预览环境，每个 PR 提交后自动生成一个带编号的测试地址，比如 http://192.168.1.100:8081。这个 8081 就得靠 Docker 启动时的端口映射来实现，否则前端同事根本看不到效果。
Docker 中的端口映射配置
在 CI 脚本里启动容器，通常会用到 docker run 命令。关键就在于 -p 参数：
docker run -d -p 8081:3000 --name my-web-app my-react-image这里的 8081:3000 表示把宿主机的 8081 端口映射到容器的 3000 端口。这样一来，外部请求访问服务器的 8081 端口，就会被转发到容器内部的服务上。
结合 CI 工具的实际配置
以 GitHub Actions 为例，如果你在部署步骤中需要启动服务并对外提供访问，workflow 文件里可以这样写：
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Build and start container
run: |
docker build -t my-app .
docker run -d -p 8080:80 --rm --name my-running-app my-app只要服务器防火墙开了 8080 端口，别人就能通过公网 IP 直接访问这个临时环境。这对快速验证功能特别有用。
多服务场景下的端口管理
有时候一个项目不止一个服务，比如前端、后端、消息队列都走自动部署。这时候就得规划好端口号，避免冲突。常见的做法是在 CI 变量里定义端口偏移量，比如 PR 编号加 8000：
PR_NUMBER=123
PORT=$((8000 + PR_NUMBER))
docker run -d -p $PORT:3000 my-app-image这样每个 PR 对应一个独立端口，互不影响。再配合 Nginx 反向代理或内网 DNS，就能生成类似 pr123.test.local 的可读地址。
端口映射看着是个小细节，但在持续集成部署流程里，它是连接“跑起来”和“能访问”的关键一环。别让服务默默运行在黑盒里，该露的端口得露出来。