ThinkPHP在K8s中启动失败因CLI模式强制关闭OPcache；队列进程不响应SIGTERM致任务中断；FileHandler在emptyDir上锁竞争拖慢日志；Alpine镜像缺mbstring扩展引发fatal error。
ThinkPHP 应用在 K8s 里启动失败：opcache.enable=0 被忽略？
不是 PHP 配置没生效，是容器镜像里 opcache.enable 被 ThinkPHP 自己的运行时检测逻辑绕过了。ThinkPHP 6+ 默认在 CLI 模式下强制关闭 OPcache（哪怕 php.ini 写了 opcache.enable=1），而 K8s 的 livenessProbe 或 startupProbe 常用 php think ping 这类命令触发，恰好走 CLI 模式。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在
config/app.php中显式设置'app_debug' => false，否则 ThinkPHP 会跳过 OPcache 初始化 - 改用 HTTP 探针，比如
curl -f http://localhost:8000/ping，避免触发 CLI 检测路径 - 若必须用 CLI 探针，在入口脚本开头加
ini_set('opcache.enable', '1');，比 php.ini 更早生效
K8s 中 think queue:work 容器反复重启：信号处理失效
ThinkPHP 的队列进程默认不响应 SIGTERM，K8s 发送终止信号后，容器等超时直接 kill -9，导致任务中断、Redis 中的 reserved 状态堆积。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 启动命令改用
php think queue:work --daemon --tries=3 --delay=3，加--daemon启用内置守护模式（支持 SIGTERM） - 在
config/queue.php中配置'retry_after' => 90，确保 Redis 中任务超时能被重新拾取 - Deployment 的
terminationGracePeriodSeconds至少设为 120，给队列优雅退出留出时间
ThinkPHP 日志写入慢拖垮 Pod：FileHandler 在 emptyDir 上锁竞争
K8s 默认的 emptyDir 卷底层是宿主机临时文件系统，多个容器副本（或同一 Pod 内多进程）并发写同一个日志目录时，FileHandler 的 flock() 会卡住，尤其在高 QPS 下出现 500ms+ 延迟。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 把日志输出重定向到
stdout，用Log::channel('stdout')替代默认File渠道 - 若必须落盘，挂载
hostPath或PV并启用fsGroup: 1001，避免权限导致的隐式锁 - 禁用 ThinkPHP 的日志自动切片（
'max_files' => 0），改由 Logrotate 或 Fluentd 统一处理
ThinkPHP 6.1+ 在 Alpine 镜像中报 mbstring extension missing
Alpine 默认 PHP 镜像不带 mbstring 扩展，但 ThinkPHP 6.1 开始在核心类（如 think\helper\Str）中无条件调用 mb_strlen()，导致容器启动即 fatal error。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- Dockerfile 中必须显式安装扩展：
apk add --no-cache php82-mbstring（注意 PHP 版本号匹配） - 不要用
php:alpine基础镜像，改用php:8.2-cli-alpine并确认php -m | grep mbstring输出存在 - CI 构建阶段加检查命令：
php -r "echo extension_loaded('mbstring') ? 'ok' : 'fail';"
真正麻烦的是混合部署场景：一个集群里既有旧版 ThinkPHP 5.1（依赖 iconv），又有新版（强依赖 mbstring），这时候扩展不能只装一半。
