实例：文件资料库（FileLib）｜技术：18 个文件、六类覆盖、路径唯一

一、种子数据的设计目标

实例 16 的种子数据要撑起「文件浏览器 + 类型筛选 + 搜索 + 统计」，设计目标：

1. 18 个文件：列表内容充实——多屏可滚；
2. 六类覆盖：文档 4 / 图片 3 / 视频 3 / 音频 2 / 压缩包 4 / 其他 2——每个类型筛选有结果；
3. 大小梯度：800KB ~ 800MB——fmtSize 换算覆盖 KB/MB 两级、总大小可观；
4. 标签丰富：tags 多词——LIKE 搜索「需求」「发布」等能命中多个文件；
5. 路径唯一：path 各不相同——演示 UNIQUE 去重；
6. 创建时间递进：30 小时前 ~ 13 小时前——倒序列表「新文件在前」。

二、18 个文件种子数据

#	名称	类型	大小	路径	标签	备注
1	项目需求文档.docx	文档	2.3MB	/docs/需求/项目需求文档.docx	需求,产品	V2.3 已评审
2	接口设计说明.pdf	文档	5MB	/docs/设计/接口设计说明.pdf	接口,后端
3	会议纪要 0620.docx	文档	800KB	/docs/会议/会议纪要0620.docx	会议,周会	待办 5 项
4	用户手册终稿.pdf	文档	8MB	/docs/文档/用户手册终稿.pdf	手册,发布
5	产品原型图.png	图片	3.5MB	/images/原型/产品原型图.png	原型,UI	首页改版
6	启动页背景.jpg	图片	4MB	/images/品牌/启动页背景.jpg	品牌,视觉	4K 原图
7	活动海报.psd	图片	25MB	/images/市场/活动海报.psd	海报,市场	618 活动
8	功能演示录屏.mp4	视频	120MB	/videos/演示/功能演示录屏.mp4	演示,测试	1080P
9	发布会宣传片.mp4	视频	350MB	/videos/市场/发布会宣传片.mp4	宣传,品牌	剪辑版
10	培训课程录像.mp4	视频	800MB	/videos/培训/培训课程录像.mp4	培训,课程
11	产品宣传曲.mp3	音频	8MB	/audio/品牌/产品宣传曲.mp3	音乐,品牌	主题曲
12	采访录音剪辑.mp3	音频	15MB	/audio/采访/采访录音剪辑.mp3	采访,媒体
13	发布包 v2.3.0.zip	压缩包	60MB	/release/v2.3.0/发布包v2.3.0.zip	发布,版本	正式版
14	素材合集.rar	压缩包	200MB	/archive/素材/素材合集.rar	素材,图片	供设计师
15	旧版备份.zip	压缩包	90MB	/archive/备份/旧版备份.zip	备份,归档	v1.0 源码
16	字体安装包.zip	压缩包	30MB	/archive/字体/字体安装包.zip	字体,设计
17	技术分享 PPT.pptx	其他	12MB	/share/技术分享PPT.pptx	PPT,分享	RDB 实战
18	行业报告 2024.xlsx	其他	6MB	/data/行业报告2024.xlsx	数据,报告

设计要点：

• 类型分布：文档 4 / 图片 3 / 视频 3 / 音频 2 / 压缩包 4 / 其他 2——GROUP BY 统计：文档 4 个排第一（cnt DESC）、音频/其他 2 个最少；
• 大小梯度：800KB（会议纪要）~ 800MB（培训录像）——fmtSize 显示「800 KB」「2.3 MB」「800.0 MB」，总大小约 1.7GB（标题栏「共 1.7GB」）；
• 标签交叉：「发布」命中用户手册终稿 + 发布包；「品牌」命中启动页背景 + 发布会宣传片 + 产品宣传曲——LIKE 搜索演示多命中；
• 路径唯一：18 条 path 各不相同——UNIQUE 约束无冲突，batchImport 跳过逻辑不触发（教学数据）；
• 时间递进：30h ~ 13h 前递减——列表顶部是「项目需求文档」（最新导入？不对，是 created_time 最早的是 30h 前——ORDER BY created_time DESC 是「时间新在前」，30h 前最旧在底部，13h 前的行业报告最新在顶部）。

三、代码实现

const now = Date.now();
const mb = 1048576;
const seed: FileSeed[] = [ /* 18 个，见第二节表格 */ ];
for (const s of seed) {
  const values: relationalStore.ValuesBucket = {
    name: s.name, file_type: s.fileType, size: s.size, path: s.path,
    tags: s.tags, note: s.note, created_time: s.createdTime,
  };
  await store.insert(FileLibDao.TABLE, values);
}
hilog.info(DOMAIN, TAG, '已填充 18 个文件种子数据');

const mb = 1048576：1MB 的字节数常量——种子大小用 2 * mb + 300 * 1024（2.3MB）表达，可读性优于裸数字。幂等保护：查 file_lib COUNT，非空即返回。

四、注入后的文件库效果预测

区块	预期效果
标题栏	「18 个文件 · 共 1.7GB」
类型筛选条	全部/文档/图片/视频/音频/压缩包/其他（动态生成）
文件列表	18 行：📄📄📄📄 文档（最新导入在前）→ 🖼️🖼️🖼️ → 🎬🎬🎬 → 🎵🎵 → 🗜️🗜️🗜️🗜️ → 📁📁
搜索「需求」	项目需求文档.docx（名称）+ 标签含需求的文件
搜索「发布」	用户手册终稿.pdf + 发布包 v2.3.0.zip（标签命中）
点「视频」	3 行 🎬（120MB / 350MB / 800MB）

演示脚本：指着标题栏说「文件库 18 个文件，总共 1.7GB」→ 划列表「文档最多，4 个；音频最少，2 个」→ 搜索框输「发布」→ 列表只剩「用户手册终稿」和「发布包」→ 清空 → 点「视频」→ 3 个视频文件（功能演示录屏 120MB、发布会宣传片 350MB、培训课程录像 800MB）。

五、验证方法

1. hilog 日志：搜 FileLibDao，看到「已填充 18 个文件种子数据」；
2. 页面显示：标题栏「18 个文件 · 共 1.7GB」、列表 18 行、类型筛选条 7 项；
3. 数据库直查：

   SELECT COUNT(*) FROM file_lib;  -- 18
   SELECT file_type, COUNT(*), SUM(size) FROM file_lib GROUP BY file_type ORDER BY COUNT(*) DESC;
   -- 文档 4 / 图片 3 / 视频 3 / 压缩包 4 / 音频 2 / 其他 2
   SELECT name FROM file_lib WHERE name LIKE '%需求%' OR tags LIKE '%需求%';
   -- 项目需求文档.docx + 标签含需求者
   SELECT SUM(size) FROM file_lib;  -- ≈1.7GB
   SELECT name FROM file_lib ORDER BY created_time DESC LIMIT 3;
   -- 行业报告2024.xlsx / 技术分享PPT.pptx / 字体安装包.zip（最新在前）
   

4. 交互验证：搜索、类型筛选、删除文件（标题栏计数减一）。

六、FAQ

Q1：为什么文档 4 个最多、音频 2 个最少？
A：真实文件库的分布——文档（需求/设计/会议/手册）数量最多、音频（宣传曲/采访）最少。GROUP BY 的 cnt DESC 排序让「文档 4」排第一，类型筛选条的动态选项与统计一致。

Q2：搜索「发布」为什么命中两个文件？
A：「用户手册终稿.pdf」tags 含「发布」、「发布包 v2.3.0.zip」名称含「发布」——LIKE OR 搜索的「名称或标签任一命中」。演示了搜索的跨字段命中能力。

Q3：800MB 的视频和 800KB 的文档怎么显示大小？
A：fmtSize 分级换算——800KB → 「800 KB」（KB 级）、2.3MB → 「2.3 MB」（MB 级 1 位小数）、800MB → 「800.0 MB」。同屏多种单位正是 fmtSize 的价值（按数量级选单位）。

Q4：路径里的目录层级（/docs/需求/）有意义吗？
A：模拟真实文件系统路径——path 是业务唯一键（同一路径不重复导入）。Demo 不解析目录层级；真实文件管理器按路径前缀做「文件夹导航」。路径的目录结构为进阶功能预留。

Q5：为什么种子不用「当前时间 ± 随机」？
A：固定偏移（now - 30h ~ now - 13h）让列表顺序确定（行业报告最新在顶）——演示可复现。随机时间会让每次启动列表顺序不同，教学演示不稳定。种子的确定性优于随机性。

Q6：18 个文件够演示吗？
A：列表约一屏半（每行 ~70px × 18 ≈ 1260px）——滚动演示充分；类型筛选每类 2~4 个有内容；搜索「发布」命中 2 个、「需求」命中 1 个+标签。数量平衡「列表充实」与「筛选可辨」。

七、文章小结

本篇文章展示了实例 16 的种子数据：18 个文件六类覆盖（文档 4/图片 3/视频 3/音频 2/压缩包 4/其他 2 + 大小 800KB~800MB 梯度 + 标签交叉 + 路径唯一 + 时间递进）。核心是「搜索与统计的种子设计」——标签交叉让 LIKE 搜索多命中、「发布」跨字段命中 2 个文件、类型分布让 GROUP BY 统计有序。文件浏览器一开屏就内容丰富、搜索有结果。

下一篇（16-5）是实例 16 的收官文章，展示 FileLibPage 全量代码与运行效果。

八、种子清单补全：18 条完整数据与时间偏移

第二节的表格给了名称/类型/大小/路径/标签/备注，本节补全「时间偏移」维度——每条种子用 now - N * H 生成 created_time，30h 递减到 13h，保证 ORDER BY created_time DESC 后「最新导入在前」可复现：

#	名称	类型	大小	路径	标签	备注	时间偏移
1	项目需求文档.docx	文档	2.3MB	/docs/需求/项目需求文档.docx	需求,产品	V2.3 已评审	now-30h
2	接口设计说明.pdf	文档	5MB	/docs/设计/接口设计说明.pdf	接口,后端		now-29h
3	会议纪要 0620.docx	文档	800KB	/docs/会议/会议纪要0620.docx	会议,周会	待办 5 项	now-28h
4	用户手册终稿.pdf	文档	8MB	/docs/文档/用户手册终稿.pdf	手册,发布		now-27h
5	产品原型图.png	图片	3.5MB	/images/原型/产品原型图.png	原型,UI	首页改版	now-26h
6	启动页背景.jpg	图片	4MB	/images/品牌/启动页背景.jpg	品牌,视觉	4K 原图	now-25h
7	活动海报.psd	图片	25MB	/images/市场/活动海报.psd	海报,市场	618 活动	now-24h
8	功能演示录屏.mp4	视频	120MB	/videos/演示/功能演示录屏.mp4	演示,测试	1080P	now-23h
9	发布会宣传片.mp4	视频	350MB	/videos/市场/发布会宣传片.mp4	宣传,品牌	剪辑版	now-22h
10	培训课程录像.mp4	视频	800MB	/videos/培训/培训课程录像.mp4	培训,课程		now-21h
11	产品宣传曲.mp3	音频	8MB	/audio/品牌/产品宣传曲.mp3	音乐,品牌	主题曲	now-20h
12	采访录音剪辑.mp3	音频	15MB	/audio/采访/采访录音剪辑.mp3	采访,媒体		now-19h
13	发布包 v2.3.0.zip	压缩包	60MB	/release/v2.3.0/发布包v2.3.0.zip	发布,版本	正式版	now-18h
14	素材合集.rar	压缩包	200MB	/archive/素材/素材合集.rar	素材,图片	供设计师	now-17h
15	旧版备份.zip	压缩包	90MB	/archive/备份/旧版备份.zip	备份,归档	v1.0 源码	now-16h
16	字体安装包.zip	压缩包	30MB	/archive/字体/字体安装包.zip	字体,设计		now-15h
17	技术分享 PPT.pptx	其他	12MB	/share/技术分享PPT.pptx	PPT,分享	RDB 实战	now-14h
18	行业报告 2024.xlsx	其他	6MB	/data/行业报告2024.xlsx	数据,报告		now-13h

第 1 条最旧（30h 前）在列表底部、第 18 条最新（13h 前）在顶部——每行递减 1 小时，等差序列便于教学推演。

九、种子设计复盘：六类分布、大小梯度、标签交叉

1. 六类分布：筛选条与统计表同源

类型	数量	总大小	代表文件
文档	4	16.1MB	用户手册终稿.pdf（8MB）
图片	3	32.5MB	活动海报.psd（25MB）
视频	3	1.27GB	培训课程录像.mp4（800MB）
音频	2	23MB	采访录音剪辑.mp3（15MB）
压缩包	4	380MB	素材合集.rar（200MB）
其他	2	18MB	技术分享PPT.pptx（12MB）
合计	18	≈1.74GB	—

数量分布 4/3/3/2/4/2 让 GROUP BY cnt DESC 有明确的排序结果；大小分布让视频独占 1.27GB（总大小 73%）——标题栏「共 1.7GB」有分量。

2. 大小梯度：fmtSize 的三级换算

数量级	文件数	fmtSize 显示示例
<1MB	1	800 KB（会议纪要）
1~10MB	7	2.3 MB / 5 MB / 8 MB
10~100MB	6	25 MB / 60 MB / 90 MB
>100MB	4	200 MB / 350 MB / 800 MB

四个数量级全覆盖——fmtSize 的 KB/MB 分支都被真实数据「点亮」，同屏出现「800 KB」「2.3 MB」「800.0 MB」三种格式，是换算函数最好的演示数据。

3. 标签交叉：一次搜索命中多个文件

关键词	命中文件	命中方式
品牌	启动页背景.jpg、发布会宣传片.mp4、产品宣传曲.mp3	标签命中 3 个
发布	用户手册终稿.pdf（标签）+ 发布包 v2.3.0.zip（名称）	跨字段命中 2 个
需求	项目需求文档.docx（名称）	名称命中 1 个

「品牌」命中 3 个靠标签交叉——三个文件分属图片/视频/音频，共享「品牌」标签；「发布」命中 2 个靠跨字段——一个在 tags、一个在 name，演示 LIKE OR 的「名称或标签任一命中」。命中数 3→2→1 刻意递减，演示三种搜索形态。

十、initSeedData 完整实现：mb 常量与时间递进

static async initSeedData(context: common.Context): Promise<void> {
  const store = await FileLibDao.getStore(context);

  // 幂等保护：文件表非空即视为已初始化，直接返回
  const count = await FileLibDao.countAll(context);
  if (count > 0) {
    hilog.info(DOMAIN, TAG, '文件库已有数据 %{public}d 条，跳过种子填充', count);
    return;
  }

  const now = Date.now();
  const mb = 1048576;        // 1MB 字节常量：size 统一用它换算
  const H = 3600 * 1000;     // 1 小时毫秒：created_time 按小时递进
  const seed: FileSeed[] = [
    { name: '项目需求文档.docx', fileType: '文档', size: 2.3 * mb, path: '/docs/需求/项目需求文档.docx', tags: '需求,产品', note: 'V2.3 已评审', createdTime: now - 30 * H },
    // ……其余 17 条按第八节表格展开，createdTime 从 now-29h 递减到 now-13h
  ];

  for (const s of seed) {
    const values: relationalStore.ValuesBucket = {
      name: s.name, file_type: s.fileType, size: s.size, path: s.path,
      tags: s.tags, note: s.note, created_time: s.createdTime,
    };
    await store.insert(FileLibDao.TABLE, values);
  }
  hilog.info(DOMAIN, TAG, '已填充 18 个文件种子数据');
}

const mb = 1048576：2.3 * mb 比裸写 2411725 可读——一眼看出「2.3MB」；const H = 3600 * 1000：now - 30 * H 比 now - 108000000 直观——「30 小时前」的语义进代码；时间递进：第 1 条 30h → 第 18 条 13h 等差递减，配合 ORDER BY created_time DESC，列表顺序稳定可复现（行业报告最新在顶）。

十一、注入后的文件库效果预测与验证 SQL

区块	预期效果	验证点
标题栏	「18 个文件 · 共 1.7GB」	SUM(size) ≈ 1.74GB
类型筛选条	全部 + 6 类 = 7 项	GROUP BY 统计驱动
文件列表	18 行，行业报告在顶、项目需求文档在底	ORDER BY created_time DESC
搜索「品牌」	3 个文件（背景/宣传片/宣传曲）	标签 LIKE 多命中
点「视频」	3 行：120MB / 350MB / 800MB	file_type = ‘视频’

-- ① 总数与总大小
SELECT COUNT(*) FROM file_lib;                      -- 18
SELECT ROUND(SUM(size) / 1048576.0 / 1024, 2) FROM file_lib;  -- ≈1.74
-- ② 六类统计（cnt DESC）
SELECT file_type, COUNT(*) AS cnt, SUM(size) AS total
FROM file_lib GROUP BY file_type ORDER BY cnt DESC;
-- ③ 标签交叉搜索
SELECT name, tags FROM file_lib WHERE tags LIKE '%品牌%';        -- 3 行
SELECT name FROM file_lib WHERE name LIKE '%发布%' OR tags LIKE '%发布%'; -- 2 行
-- ④ 时间递进验证：最新 3 条
SELECT name, created_time FROM file_lib ORDER BY created_time DESC LIMIT 3;

十二、FAQ（种子补全问答）

Q1：时间偏移为什么 30h 递减到 13h，而不是递增？
A：created_time 越大越新——13h 前的行业报告最新，DESC 排序后在列表顶部，符合「新文件在前」的直觉；若递增，顶部会是最旧的 30h 文件。递减偏移 + DESC 排序 = 演示顺序可控。

Q2：为什么大小要覆盖 800KB 到 800MB 四个数量级？
A：fmtSize 按字节数量级选单位——只有种子同时含 KB 级、MB 级、百 MB 级数据，才能同屏展示「800 KB / 2.3 MB / 800.0 MB」三种格式；若全部 2~5MB，fmtSize 会退化成「永远显示 MB」。梯度是给换算函数「出题」。

Q3：幂等保护只查 COUNT，够吗？
A：够——种子仅在首次启动填充；之后用户增删文件，COUNT > 0 即跳过，不会重复注入 18 条。严格按路径去重可逐条 EXISTS 判断，但批量场景 COUNT 保护已满足「不重复初始化」。教学场景用简单可靠的方案。

Q4：为什么「品牌」命中 3 个、「发布」2 个、「需求」1 个？
A：刻意设计成三种命中数——「品牌」靠标签交叉（跨图片/视频/音频三类）、「发布」靠跨字段（标签+名称）、「需求」靠名称。演示时依次输入三个词，搜索列表 3 行→2 行→1 行，直观展示 LIKE OR 的命中差异。命中数递减 = 搜索演示有层次。