yanhui
38fa3f2127
远端 RST 会把隧道反复踢掉（09-20 实测当天断 5 次，每次存活 15~25 分钟）。原先的 实现把「一次网络抖动」放大成「整个开发栈不可用」，根因有两处，本次一并修掉。 1) scripts/start-remote.mjs —— 隧道断了却拉着应用陪葬 隧道进程 exit 时直接 stopChildren()，把后端和前端一起杀掉，于是每一次 RST 都 升级成一次「网站打不开」，还得靠外部守护清残留、整树重启才能恢复。 改为「退避重连隧道本身，后端/前端进程不受影响」——这正是 autossh 的语义 （autossh 只负责重启 ssh，从不牵连被它服务的应用）。建立失败走 1s→30s 指数 退避，建立成功即重置退避。 顺带补齐保活参数：TCPKeepAlive=yes、ConnectTimeout=10，探活间隔 30s → 15s， 以便更快发现已被对端 RST 的死连接。 2) backend/src/config/cloudDatabase.js —— 配置负缓存被永久固化 系统库读取失败时把「空候选」写进缓存，而入口判断是 `if (cachedCloudConfigCandidates)` —— [] 在 JS 里是 truthy，于是这次失败被 永久固化：之后永不重试，直接抛「业务数据库尚未配置」500，隧道恢复了也没用， 必须重启后端。 改为「带 TTL 的负缓存」（默认 30s，可用 CLOUD_DB_CONFIG_NEGATIVE_TTL_MS 调整）： 入口用 `!== null` 判断，失败态到期自动重新解析，使隧道恢复后无需人工干预。 缓存清理收敛到 invalidateCloudConfigCache() 单点，避免日后只清数组、忘了清 TTL 时间戳而退化回「永不过期」。同时让「测试连接」入口显式失效，保证用户改完 配置点测试能立即看到真实结果。 顺带把请求超时默认值 600000ms → 60000ms：10 分钟 × maxAttempts=2 最坏挂 20 分钟，用户体感就是「卡死」；冷查实测 16~42s，60s 仍有充足余量。 验证： - 新增 backend/test/cloudDatabaseConfigCache.test.js，锁定负缓存三段语义 （TTL 内不重复解析 / 到期必须重试 / 上游恢复后自动复原且成功态不被 TTL 淘汰）； test/remote-access.test.mjs 补隧道保活参数、退避曲线，以及「自愈循环不得调用 stopChildren」的防腐化断言。 - 两处均做对照组实验：去掉保护后测试如实报错（负缓存 → 报 TTL 到期未重试； 隧道 → 把 stopChildren 加回去即被用例抓住），证明用例真能拦住回归。 - 后端全量 340 项 / 339 通过，唯一失败为 resilientSecretStore 的 Windows 权限 断言（环境固有，与本次无关）；check-syntax 通过。 - 本地实测：kill 掉隧道进程后 1 秒内自动重建（PID 36268 → 15816），后端进程 PID 未变（29580）、/health 仍返回 200。
拼多多自动化运营平台
公开的拼多多业务精简版。欢迎所有人克隆、修改、分发代码并提交 Pull Request，代码按 MIT 许可证开放。
保留商品监控、仪表盘、激励看板、营销活动、推广、商品分析、工单以及在线客户端与执行任务等现有模块。部分菜单仍沿用原项目的占位页面。
已删除市场数据、店铺管理和运营工具整组页面、Claw 对话、skills 管理、平台切换与其他平台演示页，以及对应路由、页面资源、专属配置接口和权限项。首页为仪表盘。保留业务仍使用的模型配置、商品数据查询、桌面会话和自动上架公共服务继续可用；Claw 补全与图搜备用通道已经移除，缺失资料需使用业务接口或手工补充。
本地启动
需要 Node.js 22。团队开发机器无需安装或初始化 MySQL、Redis 及第三方数据库；使用管理员发放的部署 Key，一次注册后自动连接中央系统数据库、公网 TLS Redis 和第三方数据库。完整步骤及安全边界见 远程系统数据库部署。
npm --prefix backend ci
npm --prefix frontend ci
npm run remote:dev
首次启动时填写配置请求地址和部署 Key，系统自动写入被 Git 忽略的本机配置并重启后端。保存一次性显示的管理员账号和密码后直接登录，不需要在本地创建数据库或继续执行设置向导。前端默认访问 http://localhost:5173，API 默认代理到本地后端。
验证与构建
npm --prefix backend run check
npm --prefix frontend run check
前端构建输出位于 frontend/dist。部署时需为单页应用配置路由回退，并代理 /api 与 /cubejs-api 到后端。
启动时会迁移旧侧栏配置，并删除已退役页面的权限、专属设置和专用数据表。上架测算旧偏好表中的商品分析阈值会先迁移到商品分析专用表；其他保留模块的数据不受影响。迁移仅作用于实际配置给此实例的系统数据库。
参与修改
开始开发前请阅读 仓库提交与合并规范（多用户与 AI 开发必读）。准备更新生产服务器时必须继续阅读 服务器部署规范（开发者与 AI 必读）。AI 工具的规则入口为 AGENTS.md。每个任务使用独立目录和分支，通过 PR、同步验证和独立审核合并，禁止强推或覆盖其他开发者的工作。
所有用户均可 Fork 仓库、创建分支并提交 Pull Request。直接推送本仓库需要仓库所有者授予协作者写权限。提交时请说明修改和验证结果，勿提交 .env、密码、令牌、数据库备份或真实业务数据。