灌模拟数据撑起小程序 —— 波波 2026-09-25

义父令：「往数据库灌模拟数据，先把小程序撑起来，将来可用A端清理」。

一、先查再灌：结论跟直觉不一样

动手前先摸了现状，两个发现和预想不同：

项实测结果
packages 表80 行，is_test 全为 true、零条真实数据
C端 商品列表默认返回前 50 条，全是「测试套餐001 ¥288」「测试商品描述001」
首页文案槽位content_items 的 21 个 home.* 键都有真内容（"阿里"、"冈仁波齐·阿里旅行服务"）

所以任务性质不是"加数量"，而是"把假文案换成真内容"。

游客现在打开小程序看到的就是"测试套餐001"——这正是此前 P1 上报的泄漏面；

义父的裁决是填充而非删除（空列表同样不可用），这个判断我认同。

顺带确认：C端 免登录可见的只有 4 个数据源

（miniprogram-v2/services/dsl-sources.ts）：

products / guides / recommendations(combo-cards) / weather。

其中 guides 已有 10 条真内容，真正空的就是商品。

二、做了什么

backend/sql/096_demo_packages.sql

转山朝圣 / 圣湖圣迹 / 古格土林 / 包车接送 / 住宿 / 向导陪同 / 深度摄影 / 在地体验

题材全部取自冈仁波齐与阿里的真实地名：卓玛拉山口、玛旁雍措、拉昂措、

古格王朝、扎达土林、托林寺、皮央东嘎、科迦寺、班公湖、纳木那尼峰

backend/sql/097_demo_components.sql

096 只撑起了列表——点进详情页的"包含项"还是 seed_guide / seed_driver，

一戳就露馅。按 type 批量换成真实名称，用 WHERE name LIKE 'seed_%'

保证幂等，且不碰 id<7000 那几条已有真实内容的数据。

三、执行与验证

按纪律先 staging 验脚本、再上 prod。

staging: UPDATE 80 → NOTICE: 096 OK：可见 53 条，测试字样 0，下架条目未泄漏
prod:    UPDATE 80 → NOTICE: 096 OK：可见 50 条，测试字样 0，下架条目未泄漏
（097 两侧均 UPDATE 80，seed_ 占位 0）

prod 实测接口：

冈仁波齐外转山·3天2晚经典线  2880.0  3天2晚  /images/kailash_hero_sunrise.jpg  转山朝圣
冈仁波齐外转山·2天1晚轻装版  1980.0  2天1晚  /images/kailash_hero_snow.jpg     转山朝圣
冈仁波齐外转山·4天3晚摄影深度 4680.0 4天3晚  /images/kailash_hero_night.jpg    深度摄影

「测试套餐 / 测试商品 / tag_」各出现 0 次；

首屏推荐位 combo-cards 自动跟上（与 products 同源）。

搜索"转山"命中 15 条。

四、判据踩坑（留痕）

校验最初写死「可见商品必须 = 50」⇒ staging 报 53。

查了才知道 staging 有 83 行，比 prod 多 3 条别人的数据

（id=1「转山朝圣之旅」是真内容；id=2/3 是 WIP060 测试数据且 is_test=false）。

写死条数只会换来"换个库就假失败"。 改成守三件事：

  1. 管辖范围（7001–7080）内无测试字样
  2. 标了 offline 的条目绝不泄漏到可见列表
  3. 可见商品数 ≥ 40

五、顺带发现（未擅动，均属他人域）

  1. 详情页 provider 显示英文 self / external

miniapp_products.py 里 "provider": c.get("source") or "平台自营"

直接把枚举当中文用，缺映射。属小齐域，只记录不改代码。

  1. guides 表封面指向 /images/content/，但该目录是空的 ⇒ 封面图 404。
  2. staging 列表最前 3 条是别人的数据，其中 2 条 tag=test 的测试数据仍在露脸

（prod 没有这几条，不受影响）。

六、待办