Halo 插件前端资源目录演进以ui为优先的插件 UI Bundle 解析与服务【免费下载链接】haloHalo 是一款强大易用的开源建站工具从个人博客、知识库到企业官网、在线商城Halo 都能助您轻松实现一站式满足您的多样化建站需求。项目地址: https://gitcode.com/GitHub_Trending/ha/haloHalo 的插件前端资源原先统一从resources/console目录加载这一命名只反映了早期 Console 控制台的集成方式。随着 Halo 引入 UC用户中心平台并与 Console 共享同一套插件 UI 资源机制资源目录的语义需要归一化到ui。本文以 openspec/changes/archive/2026-05-29-prefer-plugin-ui-resources/design.md 的设计为骨架结合后端运行时源码讲解 Halo 如何实现「优先ui、回退console」的插件 UI Bundle 目录选择策略以及这一策略在静态资源路由、聚合 Bundle 和插件状态StatusURL 三条路径上的一致性落地。读完本文你将理解插件打包目录resources/ui与resources/console的关系、资源 URL 的生成规则以及已有插件在升级 Halo 后无需重新打包即可继续运行的原因。背景为什么需要从console目录迁移到ui目录在 Halo 的早期设计中插件的前端 UI Bundlemain.js与style.css被约定打包在插件的console资源目录下并通过/plugins/{pluginName}/assets/console/**对外提供访问。这个命名反映的是一种「仅面向 Console 控制台」的集成方式。但当 Halo 同时支持 Console 与 UC 两套界面平台且二者共用同一套插件 UI 资源机制时console作为目录名就不再贴切——它描述的是资源的历史宿主页面而非资源本身的性质。设计文档因此将ui确立为共享资源目录的首选约定新的插件把共享前端资源打包到resources/ui下同时已有、仍按console/main.js与console/style.css打包的插件必须继续可用。受影响的三个资源面设计文档明确了改动涉及的三条既有链路它们共同决定了插件 UI 资源在运行时的可见性静态资源服务位于/plugins/{name}/assets/console/**的静态资源路由聚合 Bundle 产出从每个已启动插件的main.js与style.css汇总生成的聚合产物插件状态链接填充在资源协调Reconciliation过程中写入Plugin.status.entry与Plugin.status.stylesheet两个字段。任何一条链路如果不与其余两条使用一致的目录选择结果都会出现「运行时加载的资源」与「状态中声明的资源」不一致的混乱。明确的目标与非目标目标包括为插件资源新增默认静态资源服务/plugins/{name}/assets/ui/**在聚合 Bundle 时优先选择ui目录中的资源而非console目录对仍以console打包的存量插件保留回退能力保证 JS、CSS 与插件状态 URL 三者的 bundle 目录选择完全一致。非目标同样关键不改变公开的插件扩展 API 与Plugin数据结构Schema不重新生成 OpenAPI 客户端不改动插件构建工具的默认行为不将/assets/console/**别名到ui/**——既有路由继续服务旧console资源避免出现「URL 里写着 console 却静默返回 ui 资源」的意外。核心决策一Bundle 目录按「插件」选择而不是按「文件」选择设计的第一个关键决策是目录选择以插件为粒度优先级顺序固定为uiconsole一个目录只有在插件于该目录下**至少提供一个已知的 UI Bundle 资源main.js或style.css任一**时才被视为「可用」。一旦某个插件选中了ui目录Halo 就不会再聚合或上报该插件的consoleBundle 文件。选择「目录级、一次性判定」而非「文件级、逐个回退」是为了规避一种危险的混合结果——例如ui/main.js搭配console/style.css。这种结果会让插件运行时的实际表现取决于插件打包时是否碰巧遗漏了某个文件属于典型的隐蔽非确定性行为。按目录整体选择后插件作者得到的是完全确定的行为即便打包不完整也只会整体回退而不会拼凑出不可预测的组合。源码层面的实现证据目录选择的核心逻辑集中在 BundleResourceUtils.java目录与文件名以常量形式集中定义UI_BUNDLE_LOCATION ui、CONSOLE_BUNDLE_LOCATION console、JS_BUNDLE main.js、CSS_BUNDLE style.css候选目录数组BUNDLE_LOCATIONS {UI_BUNDLE_LOCATION, CONSOLE_BUNDLE_LOCATION}即设计文档中优先级顺序的直接映射核心方法selectBundleLocation(DefaultResourceLoader resourceLoader)依序遍历BUNDLE_LOCATIONS逐个尝试在该目录下解析main.js与style.css任一存在即返回该目录全部缺失才返回nullBundleResourceUtils.java对外的便捷入口getSelectedBundleResource(...)先选定目录再取资源旧的getJsBundleResource(...)被标记为Deprecated并直接委托给前者保证既有调用方平滑迁移。代码注释第 34 行附带了// TODO(Halo 3): Remove after legacy IIFE UI provider support ends.标记说明console目录的回退行为是面向 Halo 2.x 时代 IIFE 插件协议的兼容性通道在 Halo 3 移除旧 IIFE 支持后可以随之清理。聚合服务的二次校验另一个值得注意的实现位置是 UiPluginBundleServiceImpl.java 中的selectPluginBundleLocation(String pluginName)方法L168-L178。聚合服务的目录候选判断比静态工具类多考虑了一个因素除了main.js与style.css它还会检查ui-plugin.json常量PROVIDER_MANIFEST是否存在——因为 ESM UI 插件的入口与样式信息由该清单文件描述。若清单存在即使插件当前没有传统的main.js/style.css也应当按「具备 UI 资源」处理。三种文件任一命中即选中该目录随后该目录会被带入插件候选ProviderCandidate.bundleLocation并在生成 ESM / 传统 Provider 的 entry 与 style URL 时统一使用见providerUrl(...)中对BundleResourceUtils.buildAssetUrl(candidate.resourceName(), candidate.bundleLocation(), ...)的调用。核心决策二资源路由保持「目录专属」不互相别名第二条决策决定了静态资源的访问形态既有路由/plugins/{name}/assets/console/**继续解析console/**下的资源新增路由/plugins/{name}/assets/ui/**解析ui/**下的资源。这样设计的好处是双重的一方面旧 URL 保持稳定任何已发布插件、历史页面或第三方集成中硬编码的/assets/console/...链接都不会失效另一方面新的uiURL 语义显式清晰——URL 中写的是什么目录服务的就是什么目录绝不存在「含 console 的 URL 静默返回 ui 资源」的隐蔽行为。这条决策与「不将/assets/console/**别名到ui/**」的非目标完全呼应。在实现上插件资源 URL 的拼接集中在 BundleResourceUtils.java 的buildAssetUrl(pluginName, bundleLocation, resourceName, version)L93-L105var builder UriComponentsBuilder.fromPath(/plugins/{pluginName}/assets/{bundleLocation}/) .path(resourceName); if (StringUtils.hasText(version)) { builder.queryParam(v, version); } return builder.buildAndExpand(pluginName, bundleLocation).encode().toUriString();bundleLocation 会被参数化校验assertSupportedBundleLocation仅允许ui与console并参与资源读取路径的目录穿越防护getBundleResource中通过FileUtils.checkDirectoryTraversal(/ bundleLocation, simplifyPath)做校验。路由前缀在 PluginConst.java 中以assetsRoutePrefix(pluginName)返回/plugins/{pluginName}/assets/的方式集中定义静态资源服务、聚合产物与状态 URL 都建立在这一前缀之上。核心决策三Plugin.status的 entry 与 stylesheet 跟随选定目录第三条决策保证「状态里写什么运行时加载的就是什么」。Plugin.status.entry与Plugin.status.stylesheet不再固定指向/assets/console/...而是由聚合使用的同一目录选择结果生成选定ui时状态 URL 指向/plugins/{name}/assets/ui/main.js与/plugins/{name}/assets/ui/style.css回退到console时继续沿用旧的/assets/console/...路径。这让管理员与插件工具链能够从Plugin.status直接、明确地判断该插件当前激活的是哪一套资源布局。该逻辑位于 PluginReconciler.java 的协调方法中L558-L587log.info(Resolving main.js and style.css for plugin {}, pluginName); var resourceLoader BundleResourceUtils.getResourceLoader(pluginManager, pluginName); if (resourceLoader null) { return null; } var bundleLocation BundleResourceUtils.selectBundleLocation(resourceLoader); if (bundleLocation null) { return null; } var entryRes BundleResourceUtils.getBundleResource(resourceLoader, bundleLocation, BundleResourceUtils.JS_BUNDLE); var cssRes BundleResourceUtils.getBundleResource(resourceLoader, bundleLocation, BundleResourceUtils.CSS_BUNDLE); if (entryRes ! null entryRes.exists()) { var entry UriComponentsBuilder.newInstance() .pathSegment(plugins, pluginName, assets, bundleLocation, BundleResourceUtils.JS_BUNDLE) .queryParam(version, pluginVersion) .build(true).toString(); status.setEntry(entry); } if (cssRes ! null cssRes.exists()) { // 同理构造 stylesheet URL 并写入 status.setStylesheet(...) }注意协调器中拼装的 URL 会附带version查询参数作为缓存失效键——这与 UiPluginBundleServiceImpl.java 中为聚合资源附加版本化 cache key 的思路一脉相承保证插件升级后浏览器不会复用旧的静态资源。风险、权衡与兼容性边界设计文档对改动可能带来的副作用给出了明确的风险评估与缓解措施部分打包导致旧资源被「隐藏」若插件只把ui/main.js打进去而遗漏了ui/style.css则该插件会整体切到ui目录同插件下的console资源将不再被聚合或上报。缓解方式正是「目录级」选择本身行为确定、可测试插件作者不会遇到文件级混合的随机结果。动态 chunk 的公共路径问题带有异步代码分割动态 chunk的插件其 chunk 内引用的公共路径必须与其实际打包目录匹配。本次改动只新增/assets/ui/**的资源服务不会改写旧 chunk 中写死的 public path。因此插件迁移到ui目录后若动态加载 chunk 出现 404应当优先检查构建产物中 chunk 的公共路径配置是否指向/assets/ui/。存量测试假设部分既有测试可能只断言consoleBundle URL 的存在。缓解方式是同步更新聚焦测试同时覆盖ui优先与console回退两条路径。迁移路径与回滚这项改动不涉及任何数据迁移其迁移成本主要集中在插件侧的资源打包约定上已有插件无需任何改动只要它仍以resources/console打包Halo 就会通过console回退逻辑继续加载运行时行为与升级前完全一致新插件或准备统一目录的插件将共享前端资源打包到resources/ui一旦插件目录中出现ui/main.js或ui/style.css或 ESM 清单ui-plugin.jsonHalo 即自动为该插件启用ui目录的聚合、服务与状态 URL回滚同样简单直接还原运行时的目录选择改动即可恢复旧的「仅 console」行为而仍以console打包的插件完全不受影响。本次功能对应的能力项Capability为plugin-ui-resources完整的规格描述可参考 openspec/specs/plugin-ui-resources/spec.md原始设计档案保存在 openspec/changes/archive/2026-05-29-prefer-plugin-ui-resources/。测试覆盖与验证改动涉及的三类测试均围绕「目录选择一致性」展开对应的任务清单见 tasks.md实现覆盖分散在多个后端测试类中Bundle 资源解析测试断言ui优先级、console回退以及选中ui后对同插件console资源的目录级跳过见 BundleResourceUtilsTest.java路由测试验证/assets/ui/**的资源服务与/assets/console/**路由的共存见 PluginAutoConfigurationTest.java协调器测试断言Plugin.status.entry与Plugin.status.stylesheet在两种选中目录下分别生成正确的 URL见 PluginReconcilerTest.java。此外 UiPluginBundleServiceImplTest.java 与 UiPluginEndpointTest.java 分别覆盖了聚合服务与端点对目录选择结果的使用。就仓库当前状态而言上述任务清单中的各项已全部勾选完成即目录选择、状态字段生成与对应测试均已落地。小结「优先ui、回退console」看似只是目录顺序的调整实则是 Halo 对插件 UI 资源语义的一次关键收敛它把一个面向 Console 的历史目录约定升级为 Console 与 UC 共享的前端资源标准约定同时以「按插件整体选择」「路由目录专属」「状态 URL 与聚合目录同源」三条互相咬合的决策保证资源服务、聚合产物与状态声明三者永远指向同一个事实来源。对插件作者而言理解这套机制意味着打包目录从resources/console切换到resources/ui即可平滑迁移而无需关心运行时内部的回退细节——Halo 会替你在三条链路上做出完全一致的选择。【免费下载链接】haloHalo 是一款强大易用的开源建站工具从个人博客、知识库到企业官网、在线商城Halo 都能助您轻松实现一站式满足您的多样化建站需求。项目地址: https://gitcode.com/GitHub_Trending/ha/halo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Halo 插件前端资源目录演进以ui为优先的插件 UI Bundle 解析与服务【免费下载链接】haloHalo 是一款强大易用的开源建站工具从个人博客、知识库到企业官网、在线商城Halo 都能助您轻松实现一站式满足您的多样化建站需求。项目地址: https://gitcode.com/GitHub_Trending/ha/haloHalo 的插件前端资源原先统一从resources/console目录加载这一命名只反映了早期 Console 控制台的集成方式。随着 Halo 引入 UC用户中心平台并与 Console 共享同一套插件 UI 资源机制资源目录的语义需要归一化到ui。本文以 openspec/changes/archive/2026-05-29-prefer-plugin-ui-resources/design.md 的设计为骨架结合后端运行时源码讲解 Halo 如何实现「优先ui、回退console」的插件 UI Bundle 目录选择策略以及这一策略在静态资源路由、聚合 Bundle 和插件状态StatusURL 三条路径上的一致性落地。读完本文你将理解插件打包目录resources/ui与resources/console的关系、资源 URL 的生成规则以及已有插件在升级 Halo 后无需重新打包即可继续运行的原因。背景为什么需要从console目录迁移到ui目录在 Halo 的早期设计中插件的前端 UI Bundlemain.js与style.css被约定打包在插件的console资源目录下并通过/plugins/{pluginName}/assets/console/**对外提供访问。这个命名反映的是一种「仅面向 Console 控制台」的集成方式。但当 Halo 同时支持 Console 与 UC 两套界面平台且二者共用同一套插件 UI 资源机制时console作为目录名就不再贴切——它描述的是资源的历史宿主页面而非资源本身的性质。设计文档因此将ui确立为共享资源目录的首选约定新的插件把共享前端资源打包到resources/ui下同时已有、仍按console/main.js与console/style.css打包的插件必须继续可用。受影响的三个资源面设计文档明确了改动涉及的三条既有链路它们共同决定了插件 UI 资源在运行时的可见性静态资源服务位于/plugins/{name}/assets/console/**的静态资源路由聚合 Bundle 产出从每个已启动插件的main.js与style.css汇总生成的聚合产物插件状态链接填充在资源协调Reconciliation过程中写入Plugin.status.entry与Plugin.status.stylesheet两个字段。任何一条链路如果不与其余两条使用一致的目录选择结果都会出现「运行时加载的资源」与「状态中声明的资源」不一致的混乱。明确的目标与非目标目标包括为插件资源新增默认静态资源服务/plugins/{name}/assets/ui/**在聚合 Bundle 时优先选择ui目录中的资源而非console目录对仍以console打包的存量插件保留回退能力保证 JS、CSS 与插件状态 URL 三者的 bundle 目录选择完全一致。非目标同样关键不改变公开的插件扩展 API 与Plugin数据结构Schema不重新生成 OpenAPI 客户端不改动插件构建工具的默认行为不将/assets/console/**别名到ui/**——既有路由继续服务旧console资源避免出现「URL 里写着 console 却静默返回 ui 资源」的意外。核心决策一Bundle 目录按「插件」选择而不是按「文件」选择设计的第一个关键决策是目录选择以插件为粒度优先级顺序固定为uiconsole一个目录只有在插件于该目录下**至少提供一个已知的 UI Bundle 资源main.js或style.css任一**时才被视为「可用」。一旦某个插件选中了ui目录Halo 就不会再聚合或上报该插件的consoleBundle 文件。选择「目录级、一次性判定」而非「文件级、逐个回退」是为了规避一种危险的混合结果——例如ui/main.js搭配console/style.css。这种结果会让插件运行时的实际表现取决于插件打包时是否碰巧遗漏了某个文件属于典型的隐蔽非确定性行为。按目录整体选择后插件作者得到的是完全确定的行为即便打包不完整也只会整体回退而不会拼凑出不可预测的组合。源码层面的实现证据目录选择的核心逻辑集中在 BundleResourceUtils.java目录与文件名以常量形式集中定义UI_BUNDLE_LOCATION ui、CONSOLE_BUNDLE_LOCATION console、JS_BUNDLE main.js、CSS_BUNDLE style.css候选目录数组BUNDLE_LOCATIONS {UI_BUNDLE_LOCATION, CONSOLE_BUNDLE_LOCATION}即设计文档中优先级顺序的直接映射核心方法selectBundleLocation(DefaultResourceLoader resourceLoader)依序遍历BUNDLE_LOCATIONS逐个尝试在该目录下解析main.js与style.css任一存在即返回该目录全部缺失才返回nullBundleResourceUtils.java对外的便捷入口getSelectedBundleResource(...)先选定目录再取资源旧的getJsBundleResource(...)被标记为Deprecated并直接委托给前者保证既有调用方平滑迁移。代码注释第 34 行附带了// TODO(Halo 3): Remove after legacy IIFE UI provider support ends.标记说明console目录的回退行为是面向 Halo 2.x 时代 IIFE 插件协议的兼容性通道在 Halo 3 移除旧 IIFE 支持后可以随之清理。聚合服务的二次校验另一个值得注意的实现位置是 UiPluginBundleServiceImpl.java 中的selectPluginBundleLocation(String pluginName)方法L168-L178。聚合服务的目录候选判断比静态工具类多考虑了一个因素除了main.js与style.css它还会检查ui-plugin.json常量PROVIDER_MANIFEST是否存在——因为 ESM UI 插件的入口与样式信息由该清单文件描述。若清单存在即使插件当前没有传统的main.js/style.css也应当按「具备 UI 资源」处理。三种文件任一命中即选中该目录随后该目录会被带入插件候选ProviderCandidate.bundleLocation并在生成 ESM / 传统 Provider 的 entry 与 style URL 时统一使用见providerUrl(...)中对BundleResourceUtils.buildAssetUrl(candidate.resourceName(), candidate.bundleLocation(), ...)的调用。核心决策二资源路由保持「目录专属」不互相别名第二条决策决定了静态资源的访问形态既有路由/plugins/{name}/assets/console/**继续解析console/**下的资源新增路由/plugins/{name}/assets/ui/**解析ui/**下的资源。这样设计的好处是双重的一方面旧 URL 保持稳定任何已发布插件、历史页面或第三方集成中硬编码的/assets/console/...链接都不会失效另一方面新的uiURL 语义显式清晰——URL 中写的是什么目录服务的就是什么目录绝不存在「含 console 的 URL 静默返回 ui 资源」的隐蔽行为。这条决策与「不将/assets/console/**别名到ui/**」的非目标完全呼应。在实现上插件资源 URL 的拼接集中在 BundleResourceUtils.java 的buildAssetUrl(pluginName, bundleLocation, resourceName, version)L93-L105var builder UriComponentsBuilder.fromPath(/plugins/{pluginName}/assets/{bundleLocation}/) .path(resourceName); if (StringUtils.hasText(version)) { builder.queryParam(v, version); } return builder.buildAndExpand(pluginName, bundleLocation).encode().toUriString();bundleLocation 会被参数化校验assertSupportedBundleLocation仅允许ui与console并参与资源读取路径的目录穿越防护getBundleResource中通过FileUtils.checkDirectoryTraversal(/ bundleLocation, simplifyPath)做校验。路由前缀在 PluginConst.java 中以assetsRoutePrefix(pluginName)返回/plugins/{pluginName}/assets/的方式集中定义静态资源服务、聚合产物与状态 URL 都建立在这一前缀之上。核心决策三Plugin.status的 entry 与 stylesheet 跟随选定目录第三条决策保证「状态里写什么运行时加载的就是什么」。Plugin.status.entry与Plugin.status.stylesheet不再固定指向/assets/console/...而是由聚合使用的同一目录选择结果生成选定ui时状态 URL 指向/plugins/{name}/assets/ui/main.js与/plugins/{name}/assets/ui/style.css回退到console时继续沿用旧的/assets/console/...路径。这让管理员与插件工具链能够从Plugin.status直接、明确地判断该插件当前激活的是哪一套资源布局。该逻辑位于 PluginReconciler.java 的协调方法中L558-L587log.info(Resolving main.js and style.css for plugin {}, pluginName); var resourceLoader BundleResourceUtils.getResourceLoader(pluginManager, pluginName); if (resourceLoader null) { return null; } var bundleLocation BundleResourceUtils.selectBundleLocation(resourceLoader); if (bundleLocation null) { return null; } var entryRes BundleResourceUtils.getBundleResource(resourceLoader, bundleLocation, BundleResourceUtils.JS_BUNDLE); var cssRes BundleResourceUtils.getBundleResource(resourceLoader, bundleLocation, BundleResourceUtils.CSS_BUNDLE); if (entryRes ! null entryRes.exists()) { var entry UriComponentsBuilder.newInstance() .pathSegment(plugins, pluginName, assets, bundleLocation, BundleResourceUtils.JS_BUNDLE) .queryParam(version, pluginVersion) .build(true).toString(); status.setEntry(entry); } if (cssRes ! null cssRes.exists()) { // 同理构造 stylesheet URL 并写入 status.setStylesheet(...) }注意协调器中拼装的 URL 会附带version查询参数作为缓存失效键——这与 UiPluginBundleServiceImpl.java 中为聚合资源附加版本化 cache key 的思路一脉相承保证插件升级后浏览器不会复用旧的静态资源。风险、权衡与兼容性边界设计文档对改动可能带来的副作用给出了明确的风险评估与缓解措施部分打包导致旧资源被「隐藏」若插件只把ui/main.js打进去而遗漏了ui/style.css则该插件会整体切到ui目录同插件下的console资源将不再被聚合或上报。缓解方式正是「目录级」选择本身行为确定、可测试插件作者不会遇到文件级混合的随机结果。动态 chunk 的公共路径问题带有异步代码分割动态 chunk的插件其 chunk 内引用的公共路径必须与其实际打包目录匹配。本次改动只新增/assets/ui/**的资源服务不会改写旧 chunk 中写死的 public path。因此插件迁移到ui目录后若动态加载 chunk 出现 404应当优先检查构建产物中 chunk 的公共路径配置是否指向/assets/ui/。存量测试假设部分既有测试可能只断言consoleBundle URL 的存在。缓解方式是同步更新聚焦测试同时覆盖ui优先与console回退两条路径。迁移路径与回滚这项改动不涉及任何数据迁移其迁移成本主要集中在插件侧的资源打包约定上已有插件无需任何改动只要它仍以resources/console打包Halo 就会通过console回退逻辑继续加载运行时行为与升级前完全一致新插件或准备统一目录的插件将共享前端资源打包到resources/ui一旦插件目录中出现ui/main.js或ui/style.css或 ESM 清单ui-plugin.jsonHalo 即自动为该插件启用ui目录的聚合、服务与状态 URL回滚同样简单直接还原运行时的目录选择改动即可恢复旧的「仅 console」行为而仍以console打包的插件完全不受影响。本次功能对应的能力项Capability为plugin-ui-resources完整的规格描述可参考 openspec/specs/plugin-ui-resources/spec.md原始设计档案保存在 openspec/changes/archive/2026-05-29-prefer-plugin-ui-resources/。测试覆盖与验证改动涉及的三类测试均围绕「目录选择一致性」展开对应的任务清单见 tasks.md实现覆盖分散在多个后端测试类中Bundle 资源解析测试断言ui优先级、console回退以及选中ui后对同插件console资源的目录级跳过见 BundleResourceUtilsTest.java路由测试验证/assets/ui/**的资源服务与/assets/console/**路由的共存见 PluginAutoConfigurationTest.java协调器测试断言Plugin.status.entry与Plugin.status.stylesheet在两种选中目录下分别生成正确的 URL见 PluginReconcilerTest.java。此外 UiPluginBundleServiceImplTest.java 与 UiPluginEndpointTest.java 分别覆盖了聚合服务与端点对目录选择结果的使用。就仓库当前状态而言上述任务清单中的各项已全部勾选完成即目录选择、状态字段生成与对应测试均已落地。小结「优先ui、回退console」看似只是目录顺序的调整实则是 Halo 对插件 UI 资源语义的一次关键收敛它把一个面向 Console 的历史目录约定升级为 Console 与 UC 共享的前端资源标准约定同时以「按插件整体选择」「路由目录专属」「状态 URL 与聚合目录同源」三条互相咬合的决策保证资源服务、聚合产物与状态声明三者永远指向同一个事实来源。对插件作者而言理解这套机制意味着打包目录从resources/console切换到resources/ui即可平滑迁移而无需关心运行时内部的回退细节——Halo 会替你在三条链路上做出完全一致的选择。【免费下载链接】haloHalo 是一款强大易用的开源建站工具从个人博客、知识库到企业官网、在线商城Halo 都能助您轻松实现一站式满足您的多样化建站需求。项目地址: https://gitcode.com/GitHub_Trending/ha/halo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
 的 API 用法、生命周期回调与双通道上传原理)
