二、常见CI环境启动崩溃现象与分类归纳总结

CI环境里的启动崩溃，说起来就头疼。我接手过好几个项目，每次CI一跑就挂，本地怎么调都好好的。后来我慢慢摸清了规律——其实这些崩溃就那么几类。你想想，CI环境和本地开发机差了十万八千里，出问题太正常了。

我个人习惯是先把崩溃现象记录下来，再对照分类去排查。这样效率高得多。下面我按自己踩过的坑，把最常见的几类整理出来。

2.1 环境配置不一致

说白了，CI机器跟你本地电脑不是同一个妈生的。系统版本、预装软件、环境变量……处处都能埋雷。我记得有一次，CI上跑Python脚本报No module named 'xxx'，但本地pip list里明明有。后来发现CI用的Python 3.8，我本地是3.9，有个包在3.8上根本没编译成功。

典型的配置差异包括：

• 系统库缺失：比如缺少libssl-dev、libffi-dev这类底层依赖。
• Python版本不匹配：CI上默认Python 3.6，你用3.9的语法。
• 环境变量未设置：PATH、LD_LIBRARY_PATH没对齐。

我建议在CI脚本里统一使用Docker或conda锁定环境，别依赖宿主机的预装。比如这样：

# Dockerfile 示例
FROM python:3.9-slim
RUN apt-get update && apt-get install -y libpq-dev
COPY requirements.txt .
RUN pip install -r requirements.txt

2.2 依赖冲突与版本锁定

这个太常见了。项目大了，A包依赖B包1.x，C包又要求B包2.x，一安装就炸。CI环境下因为装的包少，冲突更容易暴露。

典型现象：

• ImportError: cannot import name 'X' from 'Y'
• 启动时报 pkg_resources.VersionConflict
• pip install 过程中直接退出

我个人习惯用pip-compile或poetry生成锁定文件，保证每次安装的版本一致。对比看看：

嗯，这里要注意：不要直接在requirements.txt里写包名>=1.0这种模糊版本，哪天它发布一个不兼容的2.0，CI就炸了。

2.3 资源限制（内存/CPU/磁盘）

CI runner通常跑在共享机器上，内存、CPU、磁盘都有限。我遇到过一个大项目启动时加载20个模型，CI机器只有2GB内存，直接OOM被kill掉。

常见表现：

• 进程突然消失，日志末尾没有报错
• 启动超时（timeout）
• 日志显示 Killed 或 exit code 137

排查方法：在CI脚本里加free -m和df -h看看资源。你可以在启动前先降级参数，比如降低线程数、限制内存使用。举个例子：

# 在启动命令前限制内存
export JAVA_OPTS="-Xmx512m -Xms256m"
python main.py --max-threads 2

2.4 代码兼容性问题

跨平台差异是个隐藏杀手。我在Windows上写的路径C:\data，到Linux CI上就变成/home/runner/data。还有编码问题：Windows默认GBK，Linux是UTF-8，读配置文件时直接乱码抛异常。

常见场景：

• 文件路径硬编码了反斜杠
• 使用了os.system('cls')这种平台相关命令
• 文本文件没有指定编码，open()时报UnicodeDecodeError

我建议从项目第一天就用pathlib和os.path.join，别偷懒写死路径。配置文件也尽量统一用YAML/JSON，别用configparser搞本地化。

2.5 测试框架与启动脚本问题

CI启动脚本本身也可能有bug。比如pytest的conftest.py里写了conftest.py里导了一个本地模块，但路径没加对；或者启动命令里环境变量没传全。

我这里有个真实案例：CI配置里写了python -m pytest tests/，但tests目录下有个__init__.py导入了上一个构建产物，那个产物在CI上没生成，pytest直接就挂了。

排查步骤：

1. 在启动前加set -x打印所有命令。
2. 检查sys.path和PYTHONPATH是否包含预期目录。
3. 手动在CI runner上跑一遍最小启动命令看看。

嗯，一个小建议：CI脚本里不要写复杂逻辑，尽量拆成单独的小脚本，每个脚本只做一件事，好调试。