必须显式跳过 Django 自动迁移检查并延迟非必需初始化：gunicorn 加 --skip-check-migrations，uWSGI 避免 --check-migrations 和 enable-threads；将 DB 连接池设为 MAX_CONNS=0，缓存预热用 threading.Timer 异步执行，OpenTelemetry 关闭冗余插件；QuerySet 避免重复求值，复用变量、用 .exists()/.count()；镜像用 slim 基础镜像、多阶段构建、精简依赖。
禁用 Django 自动迁移检查
默认 manage.py runserver 或 WSGI 启动时会同步执行 --check-migrations，扫描全部 apps 的 models 并连接数据库——这在 K8s 中直接导致 readiness probe 超时、Pod 反复重启。
必须显式跳过：
- gunicorn 启动加
--skip-check-migrations：例如gunicorn --bind :8000 --skip-check-migrations myproject.wsgi:application - uWSGI 配置中确认没写
--check-migrations，且避免enable-threads = true（可能意外触发模型扫描） - K8s YAML 的
command字段必须覆盖默认命令，不能只改args；否则仍走runserver
延迟非必需初始化逻辑
Django 的 AppConfig.ready() 或 django.db.models.signals.ready 是同步阻塞的。如果里面写了 cache.get()、redis.Redis().ping() 或 OpenTelemetry 初始化，整个进程会卡住直到依赖就绪。
正确做法是把耗时操作移出主线程：
- DB 连接池（如
django-db-geventpool）设为MAX_CONNS=0，让连接延迟到首次请求 - 缓存预热用
threading.Timer(5, lambda: cache.set_many(...))，5 秒后异步执行 - OpenTelemetry 关键环境变量：
OTEL_PYTHON_DISABLED_INSTRUMENTATIONS="requests,sqlalchemy"，关掉不需要的插件
避免 QuerySet 误用放大内存与查询开销
print(qs) 看似安全，实则触发 __repr__() 查前 20 条但不进 _result_cache；后续再 for p in qs: 就是第二次全量查询——冷启阶段反复查库+构造对象，内存和耗时双飙升。
切片也危险：qs[5:10] 生成新 QuerySet 发 LIMIT/OFFSET 查询，原 QuerySet 缓存仍为空。
调试时应：
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
- 想看内容，用
list(qs[:10])或打开DEBUG=True看 SQL 日志 - 同一查询逻辑必须复用变量；判断存在用
.exists()，要总数用.count()，别构造完整 QuerySet - 记住：QuerySet 缓存是实例级的，不是查询级的
镜像与运行时层的启动加速
Python 解释器自身启动、site-packages 扫描、pyc 编译占冷启时间近半。Docker 镜像越大，K8s 拉取+解压+挂载 rootfs 耗时越长。
关键动作：
- 基础镜像用
python:3.11-slim-bookworm替代python:3.11，体积减半 - Dockerfile 用多阶段构建：第一阶段装依赖并导出
requirements.txt，第二阶段只 COPY wheel 和必要文件 - pip install 加
--no-cache-dir --no-deps --no-install-recommends，删掉__pycache__和.dist-info - 用
pipdeptree检查未 import 的包（比如只用了requests却装了scrapy）
立即学习“Python免费学习笔记（深入）”；
冷启动优化里最容易被忽略的，是把“初始化”当成一个整体去处理——其实数据库连接、缓存探活、信号注册、第三方 SDK 加载，各自有最合适的延迟时机；强行塞进ready()，等于把所有依赖的最慢路径串成一条线。 
