必需插件激活失败时，在标准错误中找到最后的 Full diagnostics: 行；它指向 Harness home 日志目录内的唯一报告，写文件失败时完整报告则直接打印到标准错误。
DeepSeek Harness：报告在哪里？
CLI 行为参考说明，必需插件激活失败会先打印失败插件及原始堆栈，再列出 pending 插件和缺失服务。最后的 Full diagnostics: 行给出本次实际写入的报告路径。文件名形如 startup-<timestamp>-<uuid>.log，直接位于 $DSH_HOME/logs/；默认目录是 ~/.dsh/logs/。
优先使用打印出来的路径，它能标识本次尝试；旧报告不会被覆盖，也不会自动删除。如果配置的 home 不是默认位置，只查默认目录可能找不到。只有文件写入成功，CLI 才会打印文件路径。
DeepSeek Harness：启动失败后怎样操作？
- 保留启动时的标准错误，找到
Full diagnostics:，打开其中准确指定的文件，不要随意选一个旧报告。 - 如果没有路径，检查标准错误是否有报告写入错误。日志目录或文件不可写时，CLI 会同时打印写入错误和完整报告，退出码仍为 1。
- 从报告记录 profile、版本、平台、原始错误和相关插件名。对照首个失败与 pending 插件、缺失服务，不要把每个 pending 项都直接当成独立根因。
- 检查最近的配置修改是否相关。插件配置指南说明 Cordis 加载插件时使用导出的 Schema 校验配置并填充声明的默认值；无效配置可能导致加载失败。
- 分享之前检查报告，移除凭据、敏感配置和私人路径，同时保留足以理解错误及堆栈的上下文。
CLI 对配置解析、Schema、模块解析和插件启动失败都会报告非零退出，但上述特殊报告行为明确针对必需插件激活失败。只有可选插件激活警告时保留普通输出，不创建报告。不能假设每一种启动错误都会产生该文件。
| 观察 | 参考文档的说明 | 下一步 |
|---|---|---|
Full diagnostics: 后有路径 |
文件已成功写入 | 打开该准确路径 |
| 标准错误有写入错误 | 完整报告也会打印在那里 | 保留标准错误报告 |
| 只有可选插件警告 | 仅凭这些警告不创建诊断文件 | 查看普通警告输出 |
| 非零退出且无报告 | 失败可能不符合报告触发条件 | 阅读原始错误和发生阶段 |
DeepSeek Harness：完整报告包含什么？
报告包括 DSH 和 Node 版本、平台、profile、根配置路径、所有未激活插件的模块及状态、原始错误、启动警告和错误参数，也包括没有 Fiber 的导入错误。Node 检查会保留嵌套原因、聚合成员、循环引用、不可枚举属性和 Symbol 属性，不限制深度、字符串与数组长度；自定义检查器被禁用，访问器会被描述而不会求值。收集过程包含异步失败清理，并在启动结束时停止。
这些细节有助于理解简短终端摘要没有展开的堆栈或依赖链。收集器不会独立收集环境变量或配置内容；但插件原始错误本身可能包含配置或凭据。报告没有自动脱敏，即使没有单独收集配置文件，内容仍可能敏感。
DeepSeek Harness：配置校验怎样帮助排查？
插件可以导出 Config Schema，Cordis 加载时据此校验值并填充 Schema 中的默认值。因此类型或必填字段错误可能出现在启动阶段。应把实际错误与对应插件声明的字段及最近的配置变更对照；不要假设 pending 插件就是最初失败的原因。配置指南的 Schema 示例说明校验方式，并不是所有启动失败的通用修复。
需要理解组合配置时，配置层优先级介绍 bundle、profile、home 和命令行补丁的顺序。这些层可能影响加载的插件和值。保存证据前避免反复重置 profile 或修改不相关设置：诊断报告记录的是一次失败尝试，后续尝试可能产生不同报告。
对比多次尝试时怎样保留证据？
每次成功写入报告都使用唯一文件名，多次尝试可以并存。记录每个文件对应的命令、profile、时间和当时的配置状态。对比前后结果时，应关注原始错误与缺失服务的变化，而不只是统计 pending 行数。CLI 对必需激活失败会先完成报告和标准错误写入，再明确以退出码 1 退出，即使插件句柄仍然打开也是如此。因此打印路径是读取已完成报告的有效起点，但它不会替你判断根因。
报告中可能同时出现最初的插件错误、其后的等待状态和清理期间产生的消息。先保留原始顺序，查看堆栈和嵌套原因，再结合配置 Schema 判断哪些信息与最近修改有关。分享给维护者时说明本次是必需插件失败还是只有可选警告，并注明是否由标准错误提供报告，这比只发送“启动失败”更容易复现。删除敏感内容时不要把所有插件名、错误阶段和有用上下文一起删掉；也不要为了保留细节而公开凭据。检查完成后再选择可分享的副本。
配置 Schema 描述可接受的值及默认值，报告则记录本次启动观察到的失败。修改前应将两类证据对照：配置校验错误与运行时缺失服务需要分别调查。如果日志写入失败，标准错误里的完整报告同样需要检查敏感内容，不能因为它没有保存为文件就直接转发。
DeepSeek Harness：有哪些限制和安全边界？
在 POSIX 系统上，新建目录和文件分别请求 0700 与 0600 模式。文档没有把这些请求模式描述为脱敏，也没有保证每台机器的访问控制都相同。报告头提醒读者分享前检查内容；文件和复制出的标准错误都应移除密钥及私人标识，不要因为目录受限就直接公开原始日志。
完整报告提供证据，不会自动给出根因。缺失服务与 pending 插件可能是下游影响，日志也可能包含多个错误。适当保留本地原始证据，分享经过检查的副本，并区分文档明确说明的行为和自己对原因的推断。
DeepSeek Harness：相关术语是什么意思？
- 必需插件激活失败：完整启动报告的文档化触发条件。
- Pending 插件：启动诊断中列出的未激活插件。
- DSH home：成功写入报告时，其
logs/子目录保存报告的 home 目录。 - Schema 校验：加载时按插件导出 Schema 检查配置。
- 标准错误：承载启动错误的输出流；报告写入失败时也承载完整报告。
相关阅读
本文首发于 DSH Plugin 社区（dsh-plugin.com），版权归属 DSH Plugin 社区。
原文地址：https://dsh-plugin.com/zh/blog/find-the-full-diagnostics-log-when-startup-fails
