反馈渠道

反馈的目的不是表达情绪，而是让问题可复现、可定位、可验证。本页说明反馈前要做什么、一条有效反馈应包含什么，以及安全问题为什么不能公开贴细节。

先做这三步

1. 查常见问题：先看常见问题与故障排查，安装、构建、浏览器差异与宿主差异大多已有说明。
2. 查现有反馈：在仓库的 Issue 列表中搜索报错文本、插件名与关键症状，避免重复提交。
3. 确认版本与状态：对照当前状态与测试与更新记录，确认该功能是否仍处于「测试中」「实现中」或「未实现」。

如果问题在网页端与 Tauri 端表现不同，先分别记录两端结果，再判断归因；不要用一端的结果代替另一端。

在哪里反馈

渠道	用途
代码仓库 的 Issue 页面	缺陷、扩展兼容问题、文档错误、功能建议
仓库主页列出的维护者联系方式	安全漏洞、涉及凭据或隐私的问题
本站页面	只读；发现文档错误请走 Issue，不要在本站留言

提交前先看仓库的 Issue 模板与标签说明（以平台当前显示为准）。没有模板时，按下一节的要素自行组织。

有效反馈的要素

要素	要写什么	反例
环境	操作系统与版本、浏览器或 WebView 版本、运行方式（网页或 Tauri）、Node／Rust 版本	「Windows 上不行」
版本	仓库分支与提交日期，或构建产物日期；文档问题注明页面路径	「最新版」
操作步骤	从启动到复现的最短步骤，编号列出	「随便点几下就崩」
预期结果	你认为应该发生什么，依据是哪条文档或哪个契约	「应该正常」
实际结果	实际看到的现象、报错文本、错误码	「报错了」
日志	控制台、宿主日志或测试输出的相关片段；先脱敏	整份日志无说明
复现频率	每次／偶发／只在特定顺序下出现	「有时候」
范围	涉及的插件、扩展单元、数据包或资源包；是否只在某一端出现	「整个框架坏了」

补充材料能显著缩短定位时间：

• 最小复现包：只保留触发问题所需的剧本、清单与资产，使用自己编写的测试数据。
• 对照结果：同一操作在网页端与 Tauri 端、在不同渲染后端或不同浏览器下的差异。
• 时间点：问题首次出现的日期，之前是否正常。

问题分类

类型	典型内容	反馈时重点
缺陷	崩溃、卡死、状态错误、存档丢失、契约测试失败	复现步骤、日志、影响范围、是否可回退
扩展兼容	数据包、资源包、插件或 Mod 装载失败；写边被拒；版本不匹配	清单、声明的作用面与写边、装载原因码、是否签名
文档错误	页面与代码不一致、链接失效、步骤无法复现、术语前后矛盾	页面路径、原文摘录、正确行为及依据
功能建议	新能力、易用性改进、性能优化	使用场景、现状痛点、期望行为、是否愿意实现
安全问题	签名绕过、越权写入、隔离逃逸、凭据泄露、路径穿越	不要公开细节，走私下渠道

分类不必绝对准确，维护者会在受理时调整；但把「缺陷」写成「建议」会延误定位。文档与代码不一致时，以代码与测试为准，Issue 中请附上对应文件路径与测试结果。

写一条可复现的缺陷报告

标题：[缺陷] 简短描述现象与范围

环境：
- 系统：
- 运行方式：网页 / Tauri
- 浏览器或 WebView：
- 构建日期或分支：

步骤：
1.
2.
3.

预期：

实际：

日志（已脱敏）：

复现频率：

补充：是否只在某一端出现、是否与某个扩展单元有关

标题只写现象，不写猜测的根因；根因判断放在正文，并标明是推测。不要贴本机绝对路径、账号信息、令牌、私钥或完整的第三方内容。

安全问题的私下报告

安全问题不要在公开 Issue 中贴出可利用细节、利用代码、受影响数据或未修复的端点。按以下方式处理：

1. 通过仓库主页列出的维护者联系方式私下联系；若平台提供私密 Issue 或安全通告功能，优先使用该功能。
2. 说明受影响的组件与版本日期、问题类型、影响范围、复现所需条件，以及你建议的修复方向。
3. 只提供判断问题所必需的信息；不要附带他人的数据、真实凭据或大范围扫描结果。
4. 在修复发布前不要公开细节，也不要对非自有环境进行验证。
5. 维护者确认后，再协调公开说明的时间与范围。

如果问题同时涉及第三方组件，请说明组件名称与版本，便于对照其许可与安全公告；不要因此公开本站或仓库的内部配置。

反馈之后

• 维护者会按「缺陷／扩展兼容／文档／建议／安全」分流；需要补充信息时会在 Issue 中说明。
• 修复是否完成以代码、两端契约测试与更新记录为准，不以「已回复」代替「已验证」。
• 如果你的反馈改变了公开约定，相关页面会同步更新；参与代码或文档修改的规则见参与贡献。
• 对许可与品牌使用有疑问时，先读许可协议，仍不清楚再走 Issue。