诊断与自身开销
「诊断」把内存、优化效果、业务任务和通知投递放在同一入口。有额外诊断权限的用户，还能查看线程栈、日志并手动录制 JFR。
内存与 GC
查看最近 1 / 5 / 15 分钟的 GC 时间占比和 GC 后堆曲线。近期 GC 占比按累计计数的差值计算，采样不足、断档、过期或 JVM 重启时会提示数据不足。
GC 后堆曲线来自真实 GC 完成通知，保留每分钟最低值。最近一小时满足至少 10 个点、跨越 15 分钟、最近 5 分钟有新点、净增长超过 32 MiB，且至少 70% 的区间上升时，会提示持续增长。
年轻代回收后的堆量不等于全堆存活量。持续增长是继续排查的信号，不能单独判定内存泄漏；建议结合请求变化、GC 类型及 JFR 分配热点查看。
自身开销
入口：诊断 → 自身开销。首次打开查询，之后手动刷新，显示最近一小时的测量窗口。
数据记录在已有操作的起止处，不另加采样线程，也不把测量历史写入数据库。插件重启后重新累计。这里不包含所有 API 请求线程和异步通知开销，因此不代表插件的全部成本；JVM 不提供计数时显示不可用。
页头「性能诊断」弹窗中可选择「降低监控器开销」，把采样间隔设为至少 30 秒、资源归因线程上限设为至多 256。减少线程覆盖可能降低归因完整度，需要细查时可恢复标准采集。
评估效果时，在相近流量和页面状态下观察约 15 分钟，比较 Halo 进程 CPU、近期 GC 时间占比和任务开销。不要只根据插件 CPU 份额或压力评分判断是否改善。
线程栈
线程页手动查询热点线程和死锁线程，显示 CPU 增量、线程状态、锁拥有者及最多 32 层调用栈。默认展示前 30 个热点并补充死锁线程，合计最多 100 个。
若 CPU 持续偏高，先查高 CPU 线程所在的调用栈；若接口阻塞，关注线程状态、等待的锁和锁拥有者。线程列表是当次观察，不能代替连续性能分析。
日志
只读取 Halo 已配置的文件日志，不允许输入任意文件路径。可按插件、来源、级别和关键词筛选：
- 选择插件、来源、级别和每页数量，会自动查询并回到第一页。
- 关键词输入后点击查询，未提交的关键词不影响当前结果翻页。
- 结果按从新到旧展示，每页 20、50 或 100 条。
- 使用「读取新增日志」读取上次位置后的完整行；页面不自动轮询日志。
首次查询读取日志末尾最多 512 KiB，并生成固定快照。翻页期间新日志写入不会让旧结果错页。快照有效期为 5 分钟，也可能因缓存容量提前回收，过期后重新查询。
文件轮转、截断或重写时会重新定位；新增量超过读取上限时仅保留末尾范围，并提示中间记录没有读取。异常聚合只覆盖当前筛选结果，不是整个历史日志库的全文检索。
插件归属通过 logger 和异常调用栈的类名匹配，不根据消息里提到的插件名猜测。同一异常涉及多个插件时，会作为这些插件的关联日志展示，但不代表故障由其中某个插件造成。无法唯一匹配的记录留在「全部日志」。
JFR 录制
JFR 需要手动启动，可选 30、60 或 120 秒，一次只允许一个录制会话。完成后可查看 CPU 与分配热点摘要，或下载原始文件进一步分析。
录制只启用指定诊断事件，不采集 JVM 系统属性和环境变量。缓冲上限为 32 MiB，实际文件可能因块边界略有偏差。文件保存到 SQLite 同目录下的 diagnostics 文件夹，保留最近 3 份且最多 3 天；插件运行时每分钟清理，停止期间不执行清理。
重启后未完成的会话会标为中断。日志、线程栈和 JFR 都需要额外诊断权限；常见凭据会做脱敏，但业务内容仍可能出现在日志和调用栈里，分享前请检查。
业务任务、优化效果和通知投递
「业务任务」读取 Halo 实际备份记录和公开的线程池指标，展示状态、耗时、失败原因、活动数及待执行队列。未来计划任务与已到期等待任务分别处理；未公开的内部队列或第三方插件任务不能通用归属。
「优化效果」查看停用插件前后的报告及重新启用入口。「通知投递」需要管理权限，用于检查渠道状态、重试次数和下次尝试时间，详见告警与通知。