尧图网站建设 
Halo 系统初始化自动生成注册协议页面的设计与实现解析基于 openspec 变更文档与源码验证【免费下载链接】haloHalo 是一款强大易用的开源建站工具从个人博客、知识库到企业官网、在线商城Halo 都能助您轻松实现一站式满足您的多样化建站需求。项目地址: https://gitcode.com/GitHub_Trending/ha/halo本文以仓库openspec/changes/archive/2026-05-12-setup-agreement-pages/的变更设计为骨架结合 Halo 当前源码initial-data.yaml、SystemSetupEndpoint、AgreementPageFetcher等逐项验证。Halo 的注册协议用户协议 / 隐私政策同意能力由 PR #9978 引入管理员可在后台通过SystemSetting.User.requiredAgreementPages指定注册时必须同意的自定义页面SinglePage。本文将剖析它的开箱即用改造——如何在新站初始化时自动创建《用户协议》与《隐私政策》两篇页面并自动配置为注册必需协议覆盖背景痛点、目标边界、四条设计决策、初始化 YAML 落地、注册链路消费与风险迁移策略。背景现有注册协议机制与三个痛点Halo 在此之前已具备注册协议能力管理员可以在管理后台的用户设置中通过SystemSetting.User.requiredAgreementPages指定一组注册时需要勾选同意的页面。协议条目本身不是独立实体而是指向内容模型中的自定义页面SinglePage。但设计文档 design.md 明确指出该能力有三个使用障碍页面需手工创建管理员必须自行创建《服务条款》与《隐私政策》两篇 SinglePage协议配置才有可引用的对象配置需手工录入管理员还必须把页面名称手动填入设置项requiredAgreementPages新用户毫无感知首次部署 Halo 的用户不知道这套工作流导致注册协议功能实际采用率很低。与此同时Halo 已具备成熟的默认数据加载能力通过 initial-data.yaml 在初始化阶段写入默认分类、标签、文章、关于页面、菜单等。因此本变更的思路很朴素——把注册协议从手工两步操作收敛为初始化默认行为复用既有加载通道而非另起炉灶。目标与非目标Goals / Non-Goalsdesign.md 用 Goals / Non-Goals 划定了改造边界Goals要做系统初始化setup阶段自动创建两篇默认 SinglePage《用户协议》与《隐私政策》自动把这两篇页面写入requiredAgreementPages成为注册时必需的协议与既有初始化机制保持一致initial-data.yamlsystem-configurable-configmap.yaml。Non-Goals明确不做不改动前端注册页 UI——前端已通过fetchAgreementPages()动态读取协议页面不提供法律合规的协议正文——只放置占位模板提示用户替换不支持多语言协议内容——使用中文占位内容与既有默认数据风格一致不改动协议同意校验逻辑——完全复用既有UserServiceImpl.signUp()路径。四条关键设计决策Decisions决策 1用initial-data.yaml定义默认协议页面不新增 Java 初始化逻辑而是把两篇协议页面含其 Snapshot作为默认资源追加进 initial-data.yaml。这样它们与既有默认数据统一在initializeNecessaryData()中加载同时复用文件中现成的${username}、${timestamp}占位符替换机制由初始化代码替换真实用户名与时间戳。决策 2在system-configurable-configmap.yaml中配置requiredAgreementPages落点是名为system-default的 ConfigMap——系统默认配置的来源启动时自动加载。把requiredAgreementPages直接写进该文件比用 Java 运行时修改配置更简单且能保证从初始化第一刻起配置即存在无需额外设置逻辑。该文件即 system-configurable-configmap.yaml其user键以 JSON 承载用户分组默认值对应SystemSetting.User。决策 3协议页面的metadata.name使用可读名称统一采用可读名称而非随机 UUID理由有二可读名比 UUID 直观让配置自文档化也便于在system-configurable-configmap.yaml中稳定引用。最终映射页面metadata.name/slug说明服务条款 / 用户协议user-agreement注册用户协议隐私政策privacy-policy注册隐私政策决策 4页面初始状态为publish: true、visible: PUBLIC注册发生在用户未登录阶段协议页面必须对未认证用户公开可见注册页才能正常展示并打开链接。因此初始状态定为已发布 公开可见。当前仓库验证initial-data.yaml中已落地的两篇协议页面打开 initial-data.yaml协议相关段落约在 229-328 行可确认两篇协议页面已作为默认数据存在遵循 Halo 内容模型标准写法一篇Snapshot内容快照 一篇SinglePage页面本体快照通过subjectRef挂载到对应 SinglePage。《用户协议》Snapshot摘录# Terms of Service page content apiVersion: content.halo.run/v1alpha1 kind: Snapshot metadata: name: user-agreement-snapshot annotations: content.halo.run/keep-raw: true spec: subjectRef: group: content.halo.run version: v1alpha1 kind: SinglePage name: user-agreement rawType: HTML rawPatch: h2strong用户协议/strong/h2p请在此处添加你的用户协议内容。你可以在后台的 code页面/code - code自定义页面/code 中找到并编辑此页面。/pblockquotep这是一篇自动生成的页面请在发布网站前替换为实际内容。/p/blockquote contentPatch: h2strong用户协议/strong/h2p请在此处添加你的用户协议内容。你可以在后台的 code页面/code - code自定义页面/code 中找到并编辑此页面。/pblockquotep这是一篇自动生成的页面请在发布网站前替换为实际内容。/p/blockquote lastModifyTime: ${timestamp} owner: ${username} contributors: - ${username}要点content.halo.run/keep-raw: true表示保留原始内容避免后续编辑被规范化改写rawPatch/contentPatch存放 HTML 正文rawType: HTML声明渲染类型lastModifyTime与owner/contributors为初始化时替换的占位符。《用户协议》SinglePage摘录# Terms of Service page apiVersion: content.halo.run/v1alpha1 kind: SinglePage metadata: name: user-agreement spec: title: 用户协议 slug: user-agreement template: cover: owner: ${username} deleted: false publish: true baseSnapshot: user-agreement-snapshot headSnapshot: user-agreement-snapshot releaseSnapshot: user-agreement-snapshot pinned: false allowComment: false visible: PUBLIC version: 1 priority: 0 excerpt: autoGenerate: false raw: 请在此处添加你的用户协议内容。你可以在后台的 页面 - 自定义页面 中找到并编辑此页面。 htmlMetas: [] status: permalink: /user-agreement逐项对照 spec.md 中 Auto-create Terms of Service page during system setup 场景的断言全部成立以metadata.name user-agreement、slug user-agreement存在 ✅publish: true已发布✅visible: PUBLIC公开可见✅allowComment: false关闭评论✅内容为提示替换的占位文案 ✅baseSnapshot/headSnapshot/releaseSnapshot三个字段统一指向user-agreement-snapshot即快照同时作为页面基准、编辑态与发布态保证初始化后页面立即可见、可编辑。《隐私政策》页面第 280-328 行是结构完全对称的 Privacy Policy 定义快照privacy-policy-snapshot 页面privacy-policy标题隐私政策permalink: /privacy-policy同样满足publish: true、visible: PUBLIC、allowComment: false与占位内容要求。占位风格与既有默认文章 Hello Halo 一致明确提示部署者在发布前替换为符合当地法规的真实条款。初始化加载链路占位符替换与资源创建再看初始化入口 SystemSetupEndpoint.javadoInitialization(SetupRequest body)使用 ReactorMono.when(...)并行编排初始化任务管理员初始化、基础配置写入mergeToBasicConfig、initializeNecessaryData(username)创建默认数据、installPresetPlugins()/installPresetTheme()安装预设插件与主题initializeNecessaryData(username)调用loadPresetExtensions(username)读取 classpath 上initial-data.yaml构造 Properties 注入username、timestamp占位符并完成替换后逐个创建资源——两篇协议页面因此自动带上真实属主出现。值得关注的是配置写入的并发安全模式mergeToBasicConfig通过Mono.defer(...)延迟获取 ConfigMap更新后client.update(configMap)写回并配合Retry.backoff(5, Duration.ofMillis(100))过滤OptimisticLockingFailureException的重试策略处理乐观锁冲突。归档任务清单 tasks.md 的 2.1-2.3 明确新增configureAgreementPages方法读取systemConfigMap 的user分组并写入两个页面名到requiredAgreementPages将其加入doInitialization()的Mono.when并行任务并采用与mergeToBasicConfig相同的乐观锁重试策略。这与 spec 中初始化完成后requiredAgreementPages包含[user-agreement, privacy-policy]的验收场景一致。说明initial-data.yaml与system-configurable-configmap.yaml属系统默认层上面的逻辑仅在全新安装并完成初始化时执行一次既有运行实例不受影响见下文迁移计划。后台设置项requiredAgreementPages的表单与默认存储协议默认启用后管理员仍可在后台自由调整。设置项表单位于 system-setting.yaml用户设置分组- $formkit: singlePageSelect name: requiredAgreementPages label: 注册时所需协议 multiple: true if: $get(allowRegistration).value true help: 选择注册时需要用户同意的协议页面要点控件为singlePageSelect且multiple: true即后台用自定义页面多选器维护天然只允许引用真实存在的 SinglePage受allowRegistration联动控制——仅开启开放注册时展示同组还有mustVerifyEmailOnRegistration、defaultRole、protectedUsernames等配套项协议勾选属于注册策略的一部分。这些设置出厂默认值存放在system-defaultConfigMapsystem-configurable-configmap.yaml其data.user以 JSON 提供allowRegistration: false、defaultRole: guest等默认值。自动配置协议本质上是让user分组默认携带协议列表与系统默认配置合并机制天然兼容。注册链路如何消费协议AgreementPageFetcher与注册页前端协议展示依赖的能力不在本变更范围内Non-Goal但为了讲清闭环看消费端实现 AgreementPageFetcher.javafetchAgreementPages()通过systemConfigFetcher.fetch(SystemSetting.User.GROUP, SystemSetting.User.class)读取user分组配置若requiredAgreementPages为空返回空列表否则逐个按metadata.namefetch(SinglePage.class, name)拉取页面每篇页面映射为{title, permalink}返回供注册页动态渲染协议链接——注册页只需页面名列表无需部署时写死链接。PreAuthSignUpEndpoint.java 把协议列表放入注册页 modelagreementPages并针对未同意协议异常AgreementNotAcceptedException做专门处理。用户勾选后注册进入既有UserServiceImpl.signUp()校验——本变更不触碰该逻辑。这验证了设计前提注册页是协议配置的纯消费方初始化备齐页面 配置后注册页即自动出现协议链接与勾选无需任何前端改动。风险与缓解Risks / Trade-offsdesign.md 的风险表完整如下风险缓解措施用户可能不想要强制的注册协议但初始化后默认自动启用管理员可随时在管理后台清空requiredAgreementPages或删除页面行为与手工配置等价只是默认开启协议内容可能不符合当地法规页面内容带明确请替换为实际内容提示与默认文章 Hello Halo 的占位性质一致requiredAgreementPages引用了被删除的页面归档设计假设注册流程借助既有fetchAgreementPages()的错误忽略行为跳过缺失协议不影响注册主流程迁移计划与兼容性零迁移只影响全新安装的初始化流程无 API / 数据库变更、无破坏性变更见 proposal.md存量实例不受影响不会自动创建页面也不修改既有配置两篇默认协议页面拥有与手工创建 SinglePage相同的权限模型spec.md Default agreement pages can be modified or deleted by administrator管理员可自由编辑、下线或删除删除不影响其他系统功能也不阻塞注册结合上表风险缓解行理解。测试与验证归档 tasks.md 的验证路径分四层格式./gradlew spotlessApply回归./gradlew :application:test保证既有测试通过断言在SystemSetupEndpointTest中验证初始化完成后requiredAgreementPages同时包含两个协议名仓库中的 UserServiceImplTest.java 亦涉及requiredAgreementPages场景可对照理解注册协议校验的测试边界手工验证全新安装 → 完成初始化 → 注册页展示协议链接并要求勾选后方可注册。小结回顾本变更的 design.md、proposal.md 与 spec.md注册协议开箱即用的技术路径始终克制可提炼为分层闭环数据层在 initial-data.yaml 追加两对Snapshot SinglePageuser-agreement、privacy-policy复用统一默认数据加载与占位符替换当前仓库已确认落地配置层由 system-configurable-configmap.yaml 的user分组使requiredAgreementPages从初始化起即存在消费层完全不动注册前端与signUp()只依赖既有fetchAgreementPages()动态读取能力AgreementPageFetcher.java可控性占位正文提示替换、管理员可改可删、存量实例零影响。对需要在 Halo 上落地注册协议合规的场景理解这套默认数据 默认配置 前端动态消费的分层设计比在运行时打补丁更贴合 Halo 的初始化哲学。若站点已有存量用户或需二次调整则按管理后台系统 → 用户设置 → 注册时所需协议的singlePageSelect多选项维护即可全新站点则由本文所述的初始化链路自动完成全部准备。【免费下载链接】haloHalo 是一款强大易用的开源建站工具从个人博客、知识库到企业官网、在线商城Halo 都能助您轻松实现一站式满足您的多样化建站需求。项目地址: https://gitcode.com/GitHub_Trending/ha/halo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Halo 系统初始化自动生成注册协议页面的设计与实现解析：基于 openspec 变更文档与源码验证
Halo 系统初始化自动生成注册协议页面的设计与实现解析基于 openspec 变更文档与源码验证【免费下载链接】haloHalo 是一款强大易用的开源建站工具从个人博客、知识库到企业官网、在线商城Halo 都能助您轻松实现一站式满足您的多样化建站需求。项目地址: https://gitcode.com/GitHub_Trending/ha/halo本文以仓库openspec/changes/archive/2026-05-12-setup-agreement-pages/的变更设计为骨架结合 Halo 当前源码initial-data.yaml、SystemSetupEndpoint、AgreementPageFetcher等逐项验证。Halo 的注册协议用户协议 / 隐私政策同意能力由 PR #9978 引入管理员可在后台通过SystemSetting.User.requiredAgreementPages指定注册时必须同意的自定义页面SinglePage。本文将剖析它的开箱即用改造——如何在新站初始化时自动创建《用户协议》与《隐私政策》两篇页面并自动配置为注册必需协议覆盖背景痛点、目标边界、四条设计决策、初始化 YAML 落地、注册链路消费与风险迁移策略。背景现有注册协议机制与三个痛点Halo 在此之前已具备注册协议能力管理员可以在管理后台的用户设置中通过SystemSetting.User.requiredAgreementPages指定一组注册时需要勾选同意的页面。协议条目本身不是独立实体而是指向内容模型中的自定义页面SinglePage。但设计文档 design.md 明确指出该能力有三个使用障碍页面需手工创建管理员必须自行创建《服务条款》与《隐私政策》两篇 SinglePage协议配置才有可引用的对象配置需手工录入管理员还必须把页面名称手动填入设置项requiredAgreementPages新用户毫无感知首次部署 Halo 的用户不知道这套工作流导致注册协议功能实际采用率很低。与此同时Halo 已具备成熟的默认数据加载能力通过 initial-data.yaml 在初始化阶段写入默认分类、标签、文章、关于页面、菜单等。因此本变更的思路很朴素——把注册协议从手工两步操作收敛为初始化默认行为复用既有加载通道而非另起炉灶。目标与非目标Goals / Non-Goalsdesign.md 用 Goals / Non-Goals 划定了改造边界Goals要做系统初始化setup阶段自动创建两篇默认 SinglePage《用户协议》与《隐私政策》自动把这两篇页面写入requiredAgreementPages成为注册时必需的协议与既有初始化机制保持一致initial-data.yamlsystem-configurable-configmap.yaml。Non-Goals明确不做不改动前端注册页 UI——前端已通过fetchAgreementPages()动态读取协议页面不提供法律合规的协议正文——只放置占位模板提示用户替换不支持多语言协议内容——使用中文占位内容与既有默认数据风格一致不改动协议同意校验逻辑——完全复用既有UserServiceImpl.signUp()路径。四条关键设计决策Decisions决策 1用initial-data.yaml定义默认协议页面不新增 Java 初始化逻辑而是把两篇协议页面含其 Snapshot作为默认资源追加进 initial-data.yaml。这样它们与既有默认数据统一在initializeNecessaryData()中加载同时复用文件中现成的${username}、${timestamp}占位符替换机制由初始化代码替换真实用户名与时间戳。决策 2在system-configurable-configmap.yaml中配置requiredAgreementPages落点是名为system-default的 ConfigMap——系统默认配置的来源启动时自动加载。把requiredAgreementPages直接写进该文件比用 Java 运行时修改配置更简单且能保证从初始化第一刻起配置即存在无需额外设置逻辑。该文件即 system-configurable-configmap.yaml其user键以 JSON 承载用户分组默认值对应SystemSetting.User。决策 3协议页面的metadata.name使用可读名称统一采用可读名称而非随机 UUID理由有二可读名比 UUID 直观让配置自文档化也便于在system-configurable-configmap.yaml中稳定引用。最终映射页面metadata.name/slug说明服务条款 / 用户协议user-agreement注册用户协议隐私政策privacy-policy注册隐私政策决策 4页面初始状态为publish: true、visible: PUBLIC注册发生在用户未登录阶段协议页面必须对未认证用户公开可见注册页才能正常展示并打开链接。因此初始状态定为已发布 公开可见。当前仓库验证initial-data.yaml中已落地的两篇协议页面打开 initial-data.yaml协议相关段落约在 229-328 行可确认两篇协议页面已作为默认数据存在遵循 Halo 内容模型标准写法一篇Snapshot内容快照 一篇SinglePage页面本体快照通过subjectRef挂载到对应 SinglePage。《用户协议》Snapshot摘录# Terms of Service page content apiVersion: content.halo.run/v1alpha1 kind: Snapshot metadata: name: user-agreement-snapshot annotations: content.halo.run/keep-raw: true spec: subjectRef: group: content.halo.run version: v1alpha1 kind: SinglePage name: user-agreement rawType: HTML rawPatch: h2strong用户协议/strong/h2p请在此处添加你的用户协议内容。你可以在后台的 code页面/code - code自定义页面/code 中找到并编辑此页面。/pblockquotep这是一篇自动生成的页面请在发布网站前替换为实际内容。/p/blockquote contentPatch: h2strong用户协议/strong/h2p请在此处添加你的用户协议内容。你可以在后台的 code页面/code - code自定义页面/code 中找到并编辑此页面。/pblockquotep这是一篇自动生成的页面请在发布网站前替换为实际内容。/p/blockquote lastModifyTime: ${timestamp} owner: ${username} contributors: - ${username}要点content.halo.run/keep-raw: true表示保留原始内容避免后续编辑被规范化改写rawPatch/contentPatch存放 HTML 正文rawType: HTML声明渲染类型lastModifyTime与owner/contributors为初始化时替换的占位符。《用户协议》SinglePage摘录# Terms of Service page apiVersion: content.halo.run/v1alpha1 kind: SinglePage metadata: name: user-agreement spec: title: 用户协议 slug: user-agreement template: cover: owner: ${username} deleted: false publish: true baseSnapshot: user-agreement-snapshot headSnapshot: user-agreement-snapshot releaseSnapshot: user-agreement-snapshot pinned: false allowComment: false visible: PUBLIC version: 1 priority: 0 excerpt: autoGenerate: false raw: 请在此处添加你的用户协议内容。你可以在后台的 页面 - 自定义页面 中找到并编辑此页面。 htmlMetas: [] status: permalink: /user-agreement逐项对照 spec.md 中 Auto-create Terms of Service page during system setup 场景的断言全部成立以metadata.name user-agreement、slug user-agreement存在 ✅publish: true已发布✅visible: PUBLIC公开可见✅allowComment: false关闭评论✅内容为提示替换的占位文案 ✅baseSnapshot/headSnapshot/releaseSnapshot三个字段统一指向user-agreement-snapshot即快照同时作为页面基准、编辑态与发布态保证初始化后页面立即可见、可编辑。《隐私政策》页面第 280-328 行是结构完全对称的 Privacy Policy 定义快照privacy-policy-snapshot 页面privacy-policy标题隐私政策permalink: /privacy-policy同样满足publish: true、visible: PUBLIC、allowComment: false与占位内容要求。占位风格与既有默认文章 Hello Halo 一致明确提示部署者在发布前替换为符合当地法规的真实条款。初始化加载链路占位符替换与资源创建再看初始化入口 SystemSetupEndpoint.javadoInitialization(SetupRequest body)使用 ReactorMono.when(...)并行编排初始化任务管理员初始化、基础配置写入mergeToBasicConfig、initializeNecessaryData(username)创建默认数据、installPresetPlugins()/installPresetTheme()安装预设插件与主题initializeNecessaryData(username)调用loadPresetExtensions(username)读取 classpath 上initial-data.yaml构造 Properties 注入username、timestamp占位符并完成替换后逐个创建资源——两篇协议页面因此自动带上真实属主出现。值得关注的是配置写入的并发安全模式mergeToBasicConfig通过Mono.defer(...)延迟获取 ConfigMap更新后client.update(configMap)写回并配合Retry.backoff(5, Duration.ofMillis(100))过滤OptimisticLockingFailureException的重试策略处理乐观锁冲突。归档任务清单 tasks.md 的 2.1-2.3 明确新增configureAgreementPages方法读取systemConfigMap 的user分组并写入两个页面名到requiredAgreementPages将其加入doInitialization()的Mono.when并行任务并采用与mergeToBasicConfig相同的乐观锁重试策略。这与 spec 中初始化完成后requiredAgreementPages包含[user-agreement, privacy-policy]的验收场景一致。说明initial-data.yaml与system-configurable-configmap.yaml属系统默认层上面的逻辑仅在全新安装并完成初始化时执行一次既有运行实例不受影响见下文迁移计划。后台设置项requiredAgreementPages的表单与默认存储协议默认启用后管理员仍可在后台自由调整。设置项表单位于 system-setting.yaml用户设置分组- $formkit: singlePageSelect name: requiredAgreementPages label: 注册时所需协议 multiple: true if: $get(allowRegistration).value true help: 选择注册时需要用户同意的协议页面要点控件为singlePageSelect且multiple: true即后台用自定义页面多选器维护天然只允许引用真实存在的 SinglePage受allowRegistration联动控制——仅开启开放注册时展示同组还有mustVerifyEmailOnRegistration、defaultRole、protectedUsernames等配套项协议勾选属于注册策略的一部分。这些设置出厂默认值存放在system-defaultConfigMapsystem-configurable-configmap.yaml其data.user以 JSON 提供allowRegistration: false、defaultRole: guest等默认值。自动配置协议本质上是让user分组默认携带协议列表与系统默认配置合并机制天然兼容。注册链路如何消费协议AgreementPageFetcher与注册页前端协议展示依赖的能力不在本变更范围内Non-Goal但为了讲清闭环看消费端实现 AgreementPageFetcher.javafetchAgreementPages()通过systemConfigFetcher.fetch(SystemSetting.User.GROUP, SystemSetting.User.class)读取user分组配置若requiredAgreementPages为空返回空列表否则逐个按metadata.namefetch(SinglePage.class, name)拉取页面每篇页面映射为{title, permalink}返回供注册页动态渲染协议链接——注册页只需页面名列表无需部署时写死链接。PreAuthSignUpEndpoint.java 把协议列表放入注册页 modelagreementPages并针对未同意协议异常AgreementNotAcceptedException做专门处理。用户勾选后注册进入既有UserServiceImpl.signUp()校验——本变更不触碰该逻辑。这验证了设计前提注册页是协议配置的纯消费方初始化备齐页面 配置后注册页即自动出现协议链接与勾选无需任何前端改动。风险与缓解Risks / Trade-offsdesign.md 的风险表完整如下风险缓解措施用户可能不想要强制的注册协议但初始化后默认自动启用管理员可随时在管理后台清空requiredAgreementPages或删除页面行为与手工配置等价只是默认开启协议内容可能不符合当地法规页面内容带明确请替换为实际内容提示与默认文章 Hello Halo 的占位性质一致requiredAgreementPages引用了被删除的页面归档设计假设注册流程借助既有fetchAgreementPages()的错误忽略行为跳过缺失协议不影响注册主流程迁移计划与兼容性零迁移只影响全新安装的初始化流程无 API / 数据库变更、无破坏性变更见 proposal.md存量实例不受影响不会自动创建页面也不修改既有配置两篇默认协议页面拥有与手工创建 SinglePage相同的权限模型spec.md Default agreement pages can be modified or deleted by administrator管理员可自由编辑、下线或删除删除不影响其他系统功能也不阻塞注册结合上表风险缓解行理解。测试与验证归档 tasks.md 的验证路径分四层格式./gradlew spotlessApply回归./gradlew :application:test保证既有测试通过断言在SystemSetupEndpointTest中验证初始化完成后requiredAgreementPages同时包含两个协议名仓库中的 UserServiceImplTest.java 亦涉及requiredAgreementPages场景可对照理解注册协议校验的测试边界手工验证全新安装 → 完成初始化 → 注册页展示协议链接并要求勾选后方可注册。小结回顾本变更的 design.md、proposal.md 与 spec.md注册协议开箱即用的技术路径始终克制可提炼为分层闭环数据层在 initial-data.yaml 追加两对Snapshot SinglePageuser-agreement、privacy-policy复用统一默认数据加载与占位符替换当前仓库已确认落地配置层由 system-configurable-configmap.yaml 的user分组使requiredAgreementPages从初始化起即存在消费层完全不动注册前端与signUp()只依赖既有fetchAgreementPages()动态读取能力AgreementPageFetcher.java可控性占位正文提示替换、管理员可改可删、存量实例零影响。对需要在 Halo 上落地注册协议合规的场景理解这套默认数据 默认配置 前端动态消费的分层设计比在运行时打补丁更贴合 Halo 的初始化哲学。若站点已有存量用户或需二次调整则按管理后台系统 → 用户设置 → 注册时所需协议的singlePageSelect多选项维护即可全新站点则由本文所述的初始化链路自动完成全部准备。【免费下载链接】haloHalo 是一款强大易用的开源建站工具从个人博客、知识库到企业官网、在线商城Halo 都能助您轻松实现一站式满足您的多样化建站需求。项目地址: https://gitcode.com/GitHub_Trending/ha/halo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考