热修复不必绕过ci/cd但通常应绕过，因其追求快速可控；需基于线上tag、显式指定requirements路径、禁改版本字段；cherry-pick要审计冲突并最小验证；pip安装须强制重装防缓存；验证需日志标识+指标归零。
热修复必须绕过常规 CI/CD 流水线？
不是必须，但绝大多数情况下应该绕过。CI/CD 流水线通常包含耗时的测试套件、镜像构建、灰度发布检查，而热修复的核心诉求是「快且可控」——git revert 或 git cherry-pick 后直接部署到生产环境补丁分支，比等完整流水线跑完更可靠。
常见错误现象：ModuleNotFoundError: No module named 'xxx' 在热修复后突然出现，其实是 CI 流水线里隐式安装了 dev 依赖（如 pip install -e .[dev]），而热修复用的部署脚本只运行 pip install -r requirements.txt，漏掉了修复所需的临时依赖。
- 热修复分支应基于线上 tag（如
v2.4.1）而非main或develop - 部署命令必须显式指定
requirements.txt路径，避免读取错版本（例如pip install -r ./prod-requirements.txt） - 禁止在热修复中修改
setup.py或pyproject.toml的版本字段——这会污染版本号语义，后续正式发布会冲突
如何安全地 cherry-pick 单个 commit 到 hotfix 分支？
关键是避免引入无关变更和依赖冲突。cherry-pick 不是复制代码，而是重放 commit 的「差异逻辑」，一旦目标分支缺少前置依赖（比如某个函数定义或配置项），就会失败或静默出错。
使用场景：线上 OrderService.process() 抛 KeyError，本地已定位并修复，对应 commit hash 是 a1b2c3d。
立即学习“Python免费学习笔记（深入）”；
- 先确认目标分支干净：
git checkout hotfix/v2.4.1-urgent && git status --porcelain（非空则需处理） - 执行
git cherry-pick -x a1b2c3d（-x自动加注原始 commit 引用，便于审计） - 如果冲突，只解决与修复直接相关的文件（如
order_service.py），绝不要合并tests/或migrations/下的内容 - 完成后立刻运行最小验证集：
pytest tests/test_order_service.py::test_process_valid_order -xvs，不跑全量测试
pip install 热修复包时为什么总装错版本？
根本原因是 Python 包安装器默认启用 --upgrade-strategy=only-if-needed，而热修复包往往版本号不变（比如仍是 myapp==2.4.1），pip 认为「已满足」就跳过安装，实际却没更新代码。
性能影响：强制重装看似慢，但比因缓存导致旧代码残留引发二次故障代价小得多。
- 部署脚本中必须加
--force-reinstall --no-deps（禁用依赖重装可避免意外升级其他组件） - 如果用
pip install /path/to/myapp-2.4.1-py3-none-any.whl，确保 wheel 文件名中的build tag唯一（例如加+hotfix.1），否则 pip 会跳过 - 线上环境禁用
pip cache：pip config set global.cache-dir /dev/null，防止从旧缓存加载
日志和监控怎么快速确认热修复生效？
不能只看服务是否启动，要验证「修复逻辑是否真实进入执行路径」。很多团队只查 HTTP 200，结果掩盖了异常被静默吞掉的问题。
容易被忽略的地方：热修复引入的 logging.info() 如果级别高于当前 logger 配置（比如生产是 WARNING），那条日志根本不会输出。
- 在修复代码附近加一行带唯一标识的 debug 日志：
logger.debug("[HOTFIX-v2.4.1-order-keyerror] now using fallback key") - 立刻查日志系统，过滤该字符串 + 时间窗口（5 分钟内），确认有输出；没有就说明代码根本没运行
- 同时检查 metrics：比如修复前每分钟
order_process_error_total{type="KeyError"}是 120，修复后应趋近于 0，且order_process_duration_seconds_count不应突增（否则可能是 fallback 路径太慢）
