🗄️ 策略：数据库支撑的路由权威 (DB-BRA)

身份是主键。URL 只是一个指针。

---

1. 永久资源 ID (PRID) 协议

在一个真正的数据库驱动应用中，资源必须有一个即使其元数据（如标题或 URL）发生变化也能持久存在的身份。

ID 格式化规则 (严格)

ID 作为数据库中的主键。为确保与内容解耦，它必须遵循以下两种格式之一：

✅ 选项 A：数字序列 (推荐用于手动注册表)

使用结构化范围来分类内容类型。这对于在 src/mocks/content/registry-*.ts 中进行人工维护更容易。

• 核心文档：1000 - 1099
• 工程：1100 - 1199
• 基础设施：1200 - 1299
• 博客文章：2000 - 2999

✅ 选项 B：UUID / GUID (推荐用于自动生成)

如果数据是以编程方式或通过 CMS 生成的，请使用标准的 UUID v4。

• 示例：550e8400-e29b-41d4-a716-446655440000

❌ 反模式 (禁止)

永远不要使用基于 slug 或混合的 ID。它们会将身份与内容重新耦合，违背了 PRID 的初衷。

• ❌ doc-project-plan (包含语义)
• ❌ blog-2024-update (如果日期更改则会变化)

2. 解析 vs. 路由

我们已将“URL 段”与“文件路径”解耦。系统使用双路径解析策略：

路径 A：快速通道 (状态水合)

当用户在应用内导航时（例如，点击侧边栏中的链接）：

1. <Link> 组件在其 state 属性中携带 prid。

   tsx
   // ✅ 正确：不透明的 ID
   <Link to="..." state={{ prid: "1001" }} />

2. 目标页面读取 location.state.prid。
3. 数据钩子执行 getDetailById("1001")。
4. 结果：O(1) 查找。即时渲染。零歧义。

路径 B：慢速通道 (URL 重建)

当用户刷新页面或直接输入 URL 时：

1. location.state 是 undefined。
2. 加载器解析 URL slug（例如，system-design）。
3. 数据钩子执行 getDetailBySlug("system-design", "en")。
4. 结果：O(n) 映射查找。

3. 此协议的好处

• 代理弹性：如果 AI Studio 添加了 .html 或 Blob 前缀，路径 A 会完全忽略它，因为它不需要读取 URL。
• 链接稳定性：您可以将 system_design.md 重命名为 architecture_v2.md。如果您保留 Frontmatter 中的 id: 1003，所有现有的内部链接仍然有效。
• 性能：整数或固定字符的查找比字符串匹配要快得多。

---

状态：V5.1 - 数字主权已激活。