4、环境搭建：Python虚拟环境、Node.js环境、Docker环境配置、依赖管理。
说实话，做自动化链路搭建，最怕什么？
不是代码写不出来，而是环境配到一半就崩了。我见过太多人，代码写得漂亮，结果一换机器就「炸」了。嗯，这里要说的就是——把环境管好，比写代码更重要。
核心观点：环境配置不是「一次性工作」，而是「可复用的资产」。你配置的每一个虚拟环境、每一个Dockerfile，都是在为未来的自己铺路。
4.1 Python虚拟环境：隔离是美德
Python的依赖管理，说白了就是「隔离」二字。我刚开始做项目时，全局装了一堆包，结果A项目要Flask 1.x，B项目要Flask 2.x，直接冲突到怀疑人生。
虚拟环境的核心作用：每个项目拥有独立的Python解释器和包依赖，互不干扰。
4.1.1 venv：Python自带的轻量方案
Python 3.3+ 自带 venv，不需要额外安装。我个人习惯用它做快速原型。
# 创建虚拟环境
python -m venv myenv
# 激活（Windows）
myenv\Scripts\activate
# 激活（macOS/Linux）
source myenv/bin/activate
# 退出
deactivate小技巧：我习惯在项目根目录下创建 .venv 文件夹，并添加到 .gitignore 中。这样既不会污染代码仓库，又能让团队成员一眼知道「哦，这里用了虚拟环境」。
4.1.2 pip + requirements.txt：依赖锁定
虚拟环境只是第一步，依赖管理才是重头戏。我曾经因为没锁定版本，导致生产环境拉了一个破坏性更新包，服务直接挂了半小时……从那以后，我养成了「每次部署前必更新requirements.txt」的习惯。
# 导出当前环境的依赖
pip freeze > requirements.txt
# 从文件安装依赖
pip install -r requirements.txt| 命令 | 说明 | 我常用的场景 |
|---|---|---|
pip freeze |
导出所有已安装包及版本 | 锁定生产环境依赖 |
pip install -r |
批量安装依赖 | CI/CD流水线中自动安装 |
pip list --outdated |
查看可更新的包 | 定期检查依赖更新 |
注意：不要直接 pip freeze > requirements.txt 就完事了。我建议手动检查一下，去掉那些不必要的依赖（比如 pip、setuptools 本身），保持文件干净。
4.2 Node.js环境：版本切换是刚需
Node.js 的版本迭代快得吓人。你想想看，一个项目用 Node 14，另一个用 Node 18，全局装一个版本根本不够用。
我的推荐方案：nvm（Node Version Manager）
# 安装nvm（macOS/Linux）
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
# 安装指定Node版本
nvm install 18.17.0
# 切换版本
nvm use 18.17.0
# 设置默认版本
nvm alias default 18.17.0避坑指南：我曾经在Windows上折腾nvm，发现官方nvm不支持Windows。后来用了 nvm-windows 才搞定。如果你用Windows，记得去GitHub搜 coreybutler/nvm-windows。
4.2.1 package.json 与 lock 文件
Node.js 的依赖管理核心是 package.json 和 package-lock.json（或 yarn.lock）。
- package.json：声明依赖范围（如
^1.2.3表示兼容1.x.x） - lock文件：锁定精确版本，确保每次安装一致
我个人习惯：lock文件必须提交到Git仓库。这样团队所有成员、CI/CD环境都能拿到一模一样的依赖树。别问我为什么，问就是被「我本地能跑啊」坑过无数次。
4.3 Docker环境配置：一次构建，到处运行
Docker 解决了「环境一致性」这个终极难题。说白了，就是把你的应用连同操作系统、依赖、配置一起打包成一个镜像。
我参与过一个项目，开发环境是macOS，测试环境是Ubuntu，生产环境是CentOS。每次部署都要手动调一堆配置，后来用Docker一把梭，世界清净了。
4.3.1 编写Dockerfile
# 基础镜像
FROM python:3.11-slim
# 设置工作目录
WORKDIR /app
# 复制依赖文件
COPY requirements.txt .
# 安装依赖
RUN pip install --no-cache-dir -r requirements.txt
# 复制应用代码
COPY . .
# 暴露端口
EXPOSE 8000
# 启动命令
CMD ["python", "app.py"]关键点：注意 COPY 的顺序。我把 requirements.txt 先复制进去安装依赖，再复制代码。这样利用Docker的层缓存机制——只要依赖没变，这层就不会重新构建，速度能快好几倍。
4.3.2 docker-compose：多服务编排
当你的自动化链路涉及多个服务（比如Python后端 + Node.js前端 + Redis缓存），用 docker-compose 最方便。
version: '3.8'
services:
backend:
build: ./backend
ports:
- "8000:8000"
depends_on:
- redis
frontend:
build: ./frontend
ports:
- "3000:3000"
redis:
image: redis:7-alpine你想想看，一条 docker-compose up 命令，整个链路就全跑起来了。这才是自动化该有的样子。
4.4 依赖管理：版本锁定的艺术
依赖管理不是「装完就完事」，而是持续的过程。我总结了几条铁律：
- 锁定版本：无论是Python的
requirements.txt还是Node的package-lock.json，必须精确到小版本号 - 定期更新：我每两周跑一次
pip list --outdated或npm outdated，评估是否需要升级 - 安全扫描：用
safety（Python）或npm audit（Node）检查已知漏洞 - 最小依赖原则：能不用第三方库就不用。我见过一个项目为了一个工具函数装了整个lodash，得不偿失
血的教训：我曾经在生产环境直接 pip install --upgrade 了一个包，结果它依赖的底层库不兼容，整个服务挂了。从那以后，我所有依赖更新都在测试环境验证通过后，才通过CI/CD流水线发布。
4.5 知识体系总览
下面这张图，是我梳理的本章知识结构。你可以把它当作「环境配置的导航地图」。
这张图把Python、Node.js、Docker三条线串起来了。你会发现，它们虽然技术栈不同，但核心逻辑是一样的——隔离、锁定、可复现。
嗯，环境搭建这部分就聊到这儿。记住一句话：好的环境配置，是自动化链路最坚实的底座。别嫌麻烦，把这一步做扎实了，后面写代码、跑流水线都会顺畅很多。