技能介绍

它解决什么问题

CRMEB 的商品数据分散在 eb_store_product、eb_store_spu、eb_store_product_attr_value 等多张表里，只往主表 INSERT 一条记录，小程序端完全看不到这条商品——因为前端 API 走的是 SPU 表。这个技能把这类运维里的隐性依赖显式整理出来：写商品必须同时建 SPU，必须有至少一条 SKU，分类 path 必须用 /ID/ID/ 斜杠格式（逗号格式会让 findChildrenId 的 LIKE '%/72/%' 匹配失败），改完库还要重启 Swoole 并清 Redis 和 runtime/cache，否则前端读到的还是旧数据。

它如何工作

技能通过一组环境变量注入凭据（CRMEB_SSH_PASS、CRMEB_MYSQL_PASS、CRMEB_BT_USER、CRMEB_BT_PASS、CRMEB_ADMIN_USER、CRMEB_ADMIN_PASS），所有操作走 SSH 直连目标服务器：

执行 SQL：批量语句用 << 'EOSQL' heredoc 传入，避免引号和转义问题；
添加商品：依次写 eb_store_product → eb_store_spu → eb_store_product_attr_value（SKU，含 stock/price/cost）→ eb_store_product_cate → 可选的 eb_store_product_content（HTML 详情）→ 刷新缓存；
分类维护：一级分类 path 由主键拼接，二级分类在父 path 上追加，保证斜杠分隔；
缓存刷新：php think swoole stop/start 后再清 Redis；Swoole 停不掉时用 kill -9 兜底；
接口验证：直接请求小程序实际调用的端点，如 /api/product/spu/recommend、/api/product/spu/lst?cate_pid=XX、/api/store/product/category/hotranking（注意 /api/category/lst 不存在，会 404）。

服务拓扑也写清楚了：Swoole HTTP 监听 8324（不是 PHP-FPM），Nginx 通过 proxy_pass http://127.0.0.1:8324 反向代理，宝塔面板和 CRMEB 后台各有访问入口。

适用边界与注意点

文档中的服务器 IP、数据库名 crmeb_yunjinhong、项目路径 /www/wwwroot/crmeb.yunjinhong.cn、mer_id=10 是该部署环境的示例值，换成自己的环境时要同步替换；
表前缀 eb_ 和保留字 unique 需加反引号；
不要在一条 mysql 调用里混用 INSERT 和 SELECT，UPDATE 的目标表不能出现在 FROM 中，需改用 JOIN；
nginx -t 依赖 rewrite 文件存在，文件可为空但不能删除；
小程序客服类型必须选「小程序客服」，系统客服只适用于 PC/H5 端；
表结构细节见 references/schema.md，分类结构见 references/categories.md。