perf(docker): OPcache revalidate 調校 + composer 重裝條件修正 + nginx healthcheck 修復

實測修正根因：fpm 的 OPcache 本來就啟用（初版診斷是 CLI 假象），
真凶是 revalidate_freq=2 在 Windows bind mount 上每 2 秒重新 stat
全部腳本——窗口內 0.23s、窗口外 2.5s。

- local.ini：revalidate_freq 2→30、memory 192M、max_files 20000
  （程式碼變更最多 30s 生效，立即生效用 kill -USR2 1 平滑重載）
- entrypoint：composer 重裝改用 lock 內容比對，git 分支操作不再
  觸發開機重裝（原 mtime 比對造成數分鐘 502 窗口）
- healthcheck：localhost→127.0.0.1（busybox wget 先解析 ::1 而
  nginx 只 listen IPv4，導致永遠 unhealthy）

驗收：穩態 0.20~0.27s（修復前 2.3~2.5s，約 10 倍）；nginx healthy。
量測數據已寫回優化計畫文檔。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docker/php/docker-entrypoint.sh

@@ -22,9 +22,12 @@ php -r "
 file_put_contents('/var/www/.env', \$env);
 "
 
-# Composer 依賴（vendor 不存在時才裝，通常已存在於 volume）
-if [ -f "composer.json" ] && { [ ! -d "vendor" ] || [ "composer.json" -nt "vendor/autoload.php" ]; }; then
+# Composer 依賴（vendor 不存在或 lock 內容變更時才裝）
+# 用內容比對而非 mtime：git checkout/pull 會更新 composer.json 的 mtime，
+# mtime 比對會讓每次分支操作後的開機都重跑 autoload 生成（bind mount 上耗時數分鐘、期間全站 502）
+if [ -f "composer.lock" ] && { [ ! -d "vendor" ] || ! cmp -s composer.lock vendor/.composer.lock.installed; }; then
     composer install --no-scripts --optimize-autoloader
+    cp composer.lock vendor/.composer.lock.installed
 fi
 
 # 背景執行：等 MySQL → migration → cache clear → storage link → swagger

docker/php/local.ini

@@ -2,4 +2,15 @@ upload_max_filesize=40M
 post_max_size=40M
 memory_limit=512M
 max_execution_time=600
-max_input_vars=10000
+max_input_vars=10000
+
+; ── OPcache 調校（2026-06-11 效能優化 O1.1）──
+; 預設 revalidate_freq=2 在 Windows bind mount 上每 2 秒就重新 stat 全部
+; 已快取腳本（~850 檔），實測使每次閒置後的請求從 0.23s 暴增至 2.5s。
+; 拉長至 30 秒：程式碼變更最多 30 秒後生效；需要立即生效時執行
+; docker compose exec app kill -USR2 1（php-fpm 平滑重載，約 1 秒）
+opcache.enable=1
+opcache.memory_consumption=192
+opcache.max_accelerated_files=20000
+opcache.validate_timestamps=1
+opcache.revalidate_freq=30