cloud-chip.cn/.workbuddy/memory/2026-08-08.md

# 2026-08-08

## 调试：Gitea webhook "无响应"
- 现象：Gitea 推送 webhook 测试无响应；手动部署（mes2 链路）正常。
- 架构关键事实：push-to-deploy 的 webhook 接收器是**独立服务**，部署在子域 `webhook.cloud-chip.cn`（IP 47.107.30.116），**不属于**本 Laravel 项目（cloud-chip.cn 主站）；本工程的 `deploy.sh` 只是被叫醒后 `git pull` 的执行体。
- 实测结论（2026-08-08）：DNS/TLS/TCP443 全通，但 `/` 与 `/hook` 任意路径均 0 字节超时 → Nginx 活着、upstream（webhook 应用）挂掉/卡死，导致"无响应"。根因在服务端应用层，与网络/证书/本工程无关。
- 修复方向（未动手，用户选"只诊断"）：在 47.107.30.116 上查 webhook 服务进程/Nginx error.log/上游端口，重启服务；接收器应改为后台执行 deploy.sh 并立即回 200，避免同步阻塞。
- 安全提醒：Gitea webhook URL 里的 access_key 已暴露在聊天中，建议轮换。

## 修复：`config/database.php` 弃用告警（PHP 8.5）
- 现象：PHP 8.5 报 `Deprecated: Constant PDO::MYSQL_ATTR_SSL_CA is deprecated, use Pdo\Mysql::ATTR_SSL_CA instead`（config/database.php:36，mysql 连接的 `options`）。
- 修复：改为 `(\class_exists(\Pdo\Mysql::class) ? \Pdo\Mysql::ATTR_SSL_CA : \PDO::MYSQL_ATTR_SSL_CA)`。symfony/polyfill-php84 在 8.4 以下提供 `Pdo\Mysql`，故本地 8.3 与线上 8.5 均兼容。
- 验证：`php -l` 通过；本地 8.3 `class_exists` 为 true，`Pdo\Mysql::ATTR_SSL_CA` = 1009（与旧常量同值）。app 代码中仅此一处使用 `PDO::MYSQL_*`。
- 部署提醒：上传后若 config 已缓存，需 `php artisan config:clear`（或重新 `config:cache`）方生效。

## webhook 接收器架构（关键，已查清）
- `webhook.cloud-chip.cn` 是宝塔站点，文档根 /www/wwwroot/webhook.cloud-chip.cn，启用「反向代理」。
- 反代规则文件：/www/server/panel/vhost/nginx/proxy/webhook.cloud-chip.cn/2ff80e9159b517704ce43f0f74e6e247_webhook.cloud-chip.cn.conf，内容 `proxy_pass https://47.107.30.116:8698;`
- 8698 = BT-Panel（宝塔面板主进程），不是 webhook 接收器 → 流量被送进面板，导致 Gitea 测试「无响应」。
- 真正的接收器是**宝塔 WebHook 插件**（URL 格式 access_key+param 可印证），默认端口 8443；当前未运行（ss 无 8443、无 hook 进程）。
- 修复方向：安装/启动宝塔 WebHook 插件 → 反代目标改为 http://127.0.0.1:<插件端口> → nginx -s reload → 插件内自测 200 后再去 Gitea 测试。
- 注意：真正的站点 vhost 在 /www/server/panel/vhost/nginx/（不是空的 /www/server/nginx/conf/vhost/）。

## deploy.sh 增强 + 权限建议（cloud-chip.cn 生产）
- deploy.sh 已加 `php artisan config:clear` + `config:cache`（git pull 之后），避免改 config/* 后 Laravel 仍读旧缓存。config:cache 失败仅告警不中断。已由用户手动推送。
- 权限问题：生产服务器项目文件目前全归 root。要点：
  - 先确认 PHP-FPM 运行用户（宝塔默认 `www`）：`grep -r "^user" /www/server/php/*/etc/php-fpm.conf`。
  - 若 PHP-FPM 为 www：需 `chown -R www:www /www/wwwroot/cloud-chip.cn`，否则 storage/bootstrap/cache 写不进（日志/缓存/上传 Permission denied）。目录 755、文件 644，可写目录 775，.env 限 640。
  - 若 PHP-FPM 以 root 跑：当前 root 归属"能用"但 Web 进程以 root 运行不安全，仍建议改 www 并改归属。
  - 与本次修复关系：弃用修复不依赖权限（config 文件 root 644 可被 Web 读取）；关键是 deploy.sh 的 config:clear 让修复生效。权限是独立健壮性项，建议顺手做。
  - deploy.sh 中 config:cache 若以 root 运行会生成 root 所有的 config.php；因已先 config:clear 删除缓存，Laravel 直接读 config 文件，www 可读即可，无需纠结归属。

## 关键卡点：push-to-deploy 整条链断裂（2026-08-08 晚）
- 用户删除了服务器 /www/wwwroot/cloud-chip.cn 内部内容（文件夹没了代码），但**根因未变**：本地 5 个提交从未推上 origin。
- 实测（rev-parse + git cat-file）：`origin/main` 仍停在 `efc150c Initial commit`，落后本地 5 个提交；`config/database.php` 在 origin 上**缺失**。即之前"手工推送"实际未成功。
- 推送失败原因：`git push` 报 `fatal: could not read Username for https://git.coolcoth.com: terminal prompts disabled` —— 本机/本环境无 git.coolcoth.com 凭据，GCM 弹不出窗（注：git.coolcoth.com 是代码托管基础设施，地址正确；cloud-chip.cn 网站业务与 coolcoth.com 无关联，属不同主体）。
- 恢复顺序（必须先做第1步）：
  1. 把本地 5 个提交推上 origin（卡在凭据：需用户在能弹窗的终端 push，或提供 Gitea 写权限 PAT 让我用 URL 内联推送）。
  2. 服务器因文件夹已空，需重新 `git clone`（不能只 pull）：`cd /www/wwwroot && rm -rf cloud-chip.cn && git clone https://git.coolcoth.com/Lucanlee/cloud-chip.cn.git cloud-chip.cn`。
  3. 改归属 `chown -R www:www` + 目录755/文件644/可写775/.env 640。
  4. **必须去掉服务器端自动提交**：宝塔 WebHook 接收器里有 `git add -A && commit -m "实时更新" && push` 逻辑（不在 deploy.sh，在 webhook 插件脚本里），会制造 origin 分歧导致后续 pull 冲突/拉不进新代码。删掉那段。
- 提醒：webhook 接收器（宝塔 WebHook 插件，端口 8443）独立于本工程；用户删的是主站目录，不影响接收器，故 webhook 仍能触发，只是 deploy.sh 的 `git pull` 现在因目录空而失败。

## 安全/SEO/GEO 审计修复（2026-08-08 晚）
- 来源：IMA 知识库「网站测试」→ SECURITY_SEO_AUDIT.md（扫描 2026-08-06，对象 cloud-chip.cn）。
- 已落地（代码，提交 63431dd）：
  - SEO-02：Product::seoTitle() 去掉品牌后缀（app/Models/Product.php），视图统一 ` - $siteName`，消除产品页标题品牌重复。
  - SEO-05/Geo-03：布局加 WebSite+SearchAction；产品页 Product+BreadcrumbList；文章页 Article+BreadcrumbList（含作者/发布日期）。用 JSON_HEX_TAG 防 XSS。
  - SEO-06：布局加 hreflang 自引用（zh-CN/x-default）。
  - SEC-02：public/.well-known/security.txt。GEO-05：public/llms.txt。
- 已核验通过：SEC-04（本地 .env APP_DEBUG=false 等）；SEO-01（全站区块已 h2，首页 h1 来自 Hero 富文本，属后台编辑规范）。
- 未自动改（标记待办，详见 docs/SECURITY_SEO_REMEDIATION.md）：SEC-01/REL-03（CSP unsafe-inline，需 Tailwind 构建重构）、REL-02（公开页缓存，避免 CSRF 419 故全局 no-store）、REL-01/PHY-01~04（CDN/WAF/多实例/备份，云端操作）、SEC-03（composer 过旧无 audit 命令）、SEO-03/04（品牌名/title 堆砌，来自后台 site_name/seo_title_default 设置）、GEO-01/02/04/06 等（内容侧）。
- 本地记录文档（供未来开发者）：CHANGELOG.md + docs/SECURITY_SEO_REMEDIATION.md（逐项状态总表 + 改动位置 + 上线 curl 自检清单），已随 63431dd 提交。
- 推送（2026-08-08 23:40 复核）：此前「本地 5 提交未上 origin」已过时——origin/main 现已包含 63431dd（审计修复）及 bc817bf（记忆），所有本地提交已同步至 git.coolcoth.com。剩余问题纯属**服务器端**：`/www/wwwroot/cloud-chip.cn` 文件夹曾被清空，需在服务器重新 `git clone` 拉起，而非 git 推送问题。

## 澄清（2026-08-08 23:29 记录，23:4x 修订）
- 用户声明：**cloud-chip.cn 网站/业务 与 coolcoth.com 网站/业务 没有任何关系**（非同一主体/品牌）。
- 但代码托管（Gitea）确实在 `git.coolcoth.com`，该地址**正确、保持不动**——coolcoth.com 在此仅作 Git 托管基础设施（类比用 GitHub 托管），不代表两网站有关联。
- 因此此前「remote 误配、须改为 cloud-chip.cn 自有 Gitea」的判断**已撤销**，`git remote origin` 维持 `https://git.coolcoth.com/Lucanlee/cloud-chip.cn.git` 不变。
- 给未来开发者的提示：不要因为 git 主机在 coolcoth.com 就误判 cloud-chip.cn 归 coolcoth.com 所有；二者仅在「代码托管于该 Git 服务」这一点上有关，网站/品牌/业务彼此独立。

## 线上实测扫描（2026-08-08 23:5x）
- 用户称「已部署好」，遂对 cloud-chip.cn 做 curl 实测（速度+SEO/GEO）。
- **关键发现：生产部署是陈旧版本，63431dd 审计修复未上线**。证据：线上 JSON-LD 仍是旧 `Organization`（非 WebSite+SearchAction）、首页无 hreflang、产品页仍双品牌标题、security.txt/llms.txt 由 nginx 直返 404（文件不在服务器）。代码历史已同步（HEAD==origin/main==bc817bf 含 63431dd），故问题在服务器工作树/运行时未更新。
- 根因推测：①git pull 因「实时更新」自动提交造成的 origin 分歧未快进；②OPcache `validate_timestamps=Off` + 陈旧编译视图未清。已在 `docs/SECURITY_SEO_REMEDIATION.md` 写入「上线实测扫描」章节 + 服务器修复命令（`git reset --hard origin/main` + `view:clear`/`config:clear` + 重载 PHP-FPM 刷 OPcache）。
- 速度：首页热 TTFB≈0.17s、子页≈0.12s（好），gzip 已开；但 Cache-Control 全程 no-store（无缓存），且依赖外部 `cdn.tailwindcss.com`（Tailwind Play CDN，拖慢首屏且是 SEC-01 根因），无 CDN。
- SEO/GEO 评级（线上=陈旧版）：综合约 C-；正确部署 63431dd 后可达 B（良好基础），到 A 仍需解决标题规范/多 h1/CSP unsafe-inline/no-store/CDN 等遗留项。