# [Bug] dsh web 启动时反复打印 libpng warning: iCCP: known incorrect sRGB profile ——资源扫描范围疑似过宽

[Huihui-Mao]

环境

• DSH 版本：0.1.1-rc.2（@deepseek-ai/dsh）
• 系统：Windows 11
• Profile：web
• Node：v22.22.2
• 已装插件：dsh-memory-evolve、dsh-session-manager、dsh-cost-meter、dsh-files、dsh-context-doctor、dsh-better-sidebar、dsh-genui、dsh-agent-teams

现象

每次执行 dsh web 启动，控制台（PowerShell）会连续输出 50+ 行：

libpng warning: iCCP: known incorrect sRGB profile

警告在服务启动阶段即出现，无需任何用户交互；每次启动都稳定复现。

根因分析

我扫描了 dsh 相关的 94 个 PNG 文件（profile 的 node_modules + 全局 npm node_modules），其中 10 个带有 iCCP 块：

• 9 张位于 dsh-memory-evolve/docs/images/（该插件 README 的文档截图，属于文档资源，非运行时资源）。它们的 ICC profile 完全相同：MD5 9fe903287f51bd969426c28888c19682、3348 字节、profile 名为 "ICC Profile"，即 Chromium/Google 旧工具分发的经典"已知错误 sRGB 档案"。
• 1 张位于 npm/node_modules/npm/node_modules/qrcode-terminal/example/basic.png（同样是示例资源）。

推测：dsh web 启动阶段会对插件目录做资源扫描（建索引 / 缩略图 / 打包），扫描范围把 docs/、example/ 这类非运行时目录也一并卷入，并对每张 PNG 反复解码 5 次以上，于是同一批坏图产生了 50+ 行警告。该根因为基于现象的合理推测，未直接读到 dsh web 源码中的扫描代码，烦请维护者确认。

影响

• 功能上无害（PNG 仍能正常解码渲染），但严重污染控制台输出，会掩盖真正有用的启动日志和错误信息。
• 新用户容易误判为"dsh 装坏了"，增加不必要的排查成本。

复现步骤

1. 在 web profile 安装 dsh-memory-evolve（其 docs/images/ 下自带 9 张带 iCCP 的截图）；
2. 执行 dsh web；
3. 观察控制台——启动阶段即出现 50+ 行 libpng iCCP 警告。

建议（任选或组合）

1. 收窄启动时的资源扫描范围：排除 docs/、example/、test/ 等非运行时目录，只扫描真正的运行时资源目录（如 lib/、assets/、icons/）。
2. 抑制已知 iCCP 警告：在 PNG 解码路径上设置 libpng 的 PNG_SET_OPTION_STRIP_iCCP，让这类无害的 profile 警告不落到 stderr。
3. 提供日志级别控制：允许用户通过配置项关闭第三方原生库的 stderr 透传。

本地临时规避

剥离这 10 个 PNG 的 iCCP 块后重启 dsh web，警告完全消失（已验证）。但插件升级会带回带 iCCP 的原图，因此仍需上游修复。

感谢维护，期待反馈！

[liyangbing]

Separate the observed warning from the unverified scan-boundary hypothesis

The report establishes a repeatable native libpng warning on Windows and shows that removing the iCCP chunks from those ten files makes the warning disappear. It does not yet prove that DSH's startup scanner is the component opening every file, so I would first pin down that boundary before changing the decoder or suppressing stderr.

A low-cost isolation matrix would be: built-in web profile with no community plugins; the same profile with dsh-memory-evolve only; that plugin with its docs/images directory temporarily absent; then the full installed profile. Record warning count, startup phase, process identity, and the exact package-relative paths for each run. If the count follows the plugin, inspect the plugin bundle/resource manifest and the scanner's accepted roots. If it persists in the empty profile, the assumption about third-party docs is wrong and the built-in asset path needs tracing.

Preferred remediation boundary

If the attribution is confirmed, make startup consume declared runtime assets (for example assets/icons) or an explicit bundle manifest, rather than recursively treating every node_modules PNG as runtime input. Keep docs, examples, and tests out at that boundary. If a native decoder still sees user-supplied PNGs, normalize or validate them at packaging/import time with a scoped diagnostic; a process-wide stderr mute would hide unrelated image failures.

Regression evidence

1. A clean built-in profile emits no iCCP warning.
2. Installing documentation-only PNGs does not change the warning count.
3. Runtime icons and user images still render, including valid non-sRGB profiles.
4. A malformed or unreadable runtime asset remains an attributable error rather than disappearing into a global suppression.
5. The test records the selected profile, package root, scanned paths, warning count, and startup phase so a future scanner expansion is visible.

The proposed directory exclusions are therefore a good fix candidate, but the isolation matrix should land first as evidence that the scanner—not another native dependency—is the owner of the noise.

[argszero]

源码核对（0.1.2-alpha.1，cd5ef81481；OP 在 rc.2，若 rc.2 有差异以实际版本为准，但以下两个核心事实与版本无关）："dsh web 启动时扫描插件目录资源并解码 PNG"这个根因假设，在 alpha.1 树内得不到支持，且有一个文件位置直接否证了"dsh 是打开者"。

树内事实：

• 全树唯一基于 libpng 的解码器是 sharp（@deepseek-ai/dsh-attachment-local 依赖），全部调用点都在附件读写路径（image.ts:93/:116 的 metadata/normalize、encoding/normalization/request-image），全部由用户操作触发（存附件/读附件/归一化），启动阶段无任何调用。
• web-app bundle 挂的是 webserver + frontend-static（SPA dist 字节直发，readFile 原样返回，无解码）；全树无 icon/logo/favicon 扫描、无 readdir 式图片遍历、无缩略图生成。"资源扫描/建索引/打包"在 alpha.1 不存在。

决定性反证（与版本无关）：第 10 个文件是 npm/node_modules/npm/node_modules/qrcode-terminal/example/basic.png——它在 npm CLI 自己的安装树里。dsh（任何版本）没有任何代码路径读取 npm 的 node_modules；如果该文件的警告真的出现，打开者不可能是 dsh 的启动扫描器。建议把这个文件从计数中剔除，它会污染归因。

最可能的打开者：10 个文件中 9 个在第三方插件 dsh-memory-evolve/docs/images/ 里。该插件"memory evolve"定位决定了它很可能在启动时对自身/邻近目录做记忆索引（读图片做视觉记忆或元数据），若它用 sharp/libpng 解码就会逐文件产生这些警告。修复归属应指向该插件包，而非 dsh core——OP 的三个建议（收窄扫描/剥离 iCCP/抑制 stderr）都预设"dsh 拥有扫描"，这个预设不成立。

判别实验（比矩阵更省事的决定性两步）：

1. 只卸载 dsh-memory-evolve 后重启 dsh web——若警告消失，归因即定（该插件）；
2. Windows 上用 Process Monitor（procmon）过滤 basic.png 与 docs/images 的 CreateFile——直接看是哪个进程在打开，比推测任何组件都快，也顺带验证第 10 个文件的真实打开者。
   若在零社区插件的内置 profile 下警告仍出现，才需要回头查 dsh core（届时 alpha.1 树内证据已排除 sharp 与静态服务，线索会指向 CLI 树外或系统级工具）。

另：OP 已验证"剥离 iCCP 块后警告消失"，这本身是好的缓解手段，但若根因在第三方插件，插件升级会带回原图（OP 已预见）。把判别实验做完再决定修哪一侧，避免在 dsh core 上为第三方插件的行为打补丁。

[Huihui-Mao]

您的源码核对成立，我的根因假设（dsh 启动时扫描插件目录并解码 PNG）不成立，抱歉占用时间。

补充我在 rc.2 上的实测，供参考：memory-evolve 的 host 端未引用任何图片解码库（sharp/jimp/pngjs/libvips 均无），因此"该插件用 sharp 解码"这条推测在本机也不成立；dsh-files 的 detect.js 只用 magic bytes 判类型（源码注释 "never decompresses anything"）且只扫 .dsh-filess/；cost-meter 只扫 sessions。全部插件都被排除。此外我补扫了 .dsh-filess 会话附件，14 张图带 iCCP 的为 0。

现状矛盾：剥离那 10 个文件的 iCCP 后警告确实消失（已验证），但静态分析找不到打开者。qrcode-terminal 那个文件按您的论证应从计数中剔除，我同意——剩下 9 张都在 memory-evolve/docs/images。

我下一步按你建议做判别实验（先恢复 9 张 → 重启看是否复现；再用 procmon 抓 CreateFile 看进程名）。