主题
HNCore v1.3.0
- 发布日期：2026-04-15
- 发布提交：
371d7de - 版本定位：从臃肿主类模式迁移到注解驱动的生命周期管理，为下游插件提供可复用的编排基础设施
版本定位
v1.3.0 这一轮的核心目标是 架构重构，而不是功能新增。
在 v1.1.0 补齐公共基础设施后，HNCore 主类承担了所有服务的编排和透传职责（409 行代码中 220 行是纯 getter 透传），这导致：
- 每次新增服务都要修改主类
- 下游插件无法复用 HNCore 的编排能力
- 生命周期管理逻辑散落在主类各处
这一轮通过引入 注解驱动的生命周期管理系统，把主类从"服务容器 + 编排器"精简为"启动入口"，同时把编排能力开放给下游插件复用。
本次重点新增 / 调整
1. 注解驱动的生命周期管理系统
来源提交：371d7de（2026-04-15，架构重构：引入注解驱动生命周期管理）
新增四个核心组件：
@Awake：标记生命周期方法（INIT/LOAD/ENABLE/ACTIVE/DISABLE），支持优先级控制@AutoListener：标记事件监听方法，自动注册到 Bukkit 事件系统@AutoSchedule：标记定时任务方法，支持延迟、周期、异步配置PluginScanner：核心扫描和驱动引擎，负责发现注解并按优先级驱动执行
这套系统已纳入 hncore-api 发布范围，下游插件可以直接依赖使用。
2. 主类精简与服务注册表解耦
来源提交：371d7de（2026-04-15，架构重构：引入注解驱动生命周期管理）
- 新增
HNCoreServices静态注册表：各组件自注册，主类 getter 从注册表取值 - 新增
HNCoreBootstrap：所有初始化逻辑用@Awake标记，按 priority 顺序驱动 - 主类精简：
onEnable从 33 行精简为 4 行onDisable从 17 行精简为 2 行- 不再承担服务编排职责，只做启动入口
3. 下游插件可复用的编排能力
这一轮最重要的变化不是 HNCore 自己用了什么，而是 下游插件现在可以复用同一套编排基础设施。
参考 NeigeItems、NuStarParty、Baikiruto 等项目的实践，主类不应该做事，只做编排。现在 HNCore 把这套编排能力开放出来了：
- 下游插件可以用
@Awake管理自己的生命周期 - 下游插件可以用
@AutoListener自动注册事件监听 - 下游插件可以用
@AutoSchedule自动注册定时任务 - 下游插件可以用
PluginScanner驱动自己的组件扫描
下游接入建议
如果你是 HN 系列下游插件开发者，建议优先围绕下面这套编排基础设施实现业务：
- 生命周期管理：
@Awake、PluginScanner - 事件监听：
@AutoListener - 定时任务：
@AutoSchedule - 服务注册：参考
HNCoreServices的静态注册表模式
升级提醒
- 如果你是 服主，这次升级是架构重构，功能行为不变，可以平滑升级
- 如果你是 下游模块开发者，建议评估是否迁移到 HNCore 的注解驱动生命周期管理，避免主类臃肿
- 如果你的现有模块已经自带一套 生命周期编排逻辑，升级到这轮后建议评估是否逐步迁移到 HNCore 的统一协议
- 如果你依赖 HNCore 主类的 getter 方法，升级后这些方法仍然保留，但内部实现已改为从
HNCoreServices注册表取值
升级后建议检查
建议升级到 v1.3.0 后优先做下面几类回归：
核心状态检查
- 执行
/hncore status - 确认核心服务、共享存储与依赖状态正常
- 执行
生命周期检查
- 检查插件启动、重载、关闭流程是否正常
- 检查事件监听是否正常触发
- 检查定时任务是否正常执行
下游插件兼容性检查
- 检查依赖 HNCore 的下游插件是否正常启动
- 检查下游插件调用 HNCore API 是否正常
二开接入检查
- 如果你自己有下游插件，建议重新对照这几页文档检查接入面是否仍合理：