Support and Issue Reporting zh CN

获取帮助与问题反馈

语言： English · 简体中文

高质量的 LWC issue 应说明预期是什么、canonical 状态实际是什么、哪一项派生能力与它不一致，以及当前是否可以安全恢复。分享任何证据前，都要移除秘密和客户数据。

选择正确渠道

需求	渠道
可复现缺陷	GitHub Issues
文档修正	提交 GitHub issue，写明 Wiki 页面和具体 claim
功能或兼容请求	提交 GitHub issue，附用户问题与宿主官方证据
敏感安全漏洞	仓库安全策略
MarkItDown、AnyDoc 或 Agent 宿主上游故障	先确认责任边界，再反馈给对应上游项目

疑似 secret、可利用路径、私有 Source body 或客户数据集都不能发布到公开 issue。

反馈前先诊断

只针对受影响 scope 执行：

lwc --version
lwc --scope project config show
lwc --scope project lint --limit 100
lwc --scope project work list
lwc --scope project graph status
lwc --scope project graph verify
lwc --scope project cg status
lwc agent status --target auto --location global

命令失败时，应保留完整结构化 error。如果其中声明 canonical 部分成功，不要重新执行业务 mutation；先按返回的恢复契约处理。

最小缺陷报告

至少包含：

1. 一句话说明预期结果；
2. 准确命令与 scope；
3. LWC version、操作系统、架构和安装渠道；
4. 完整 error.code 与脱敏后的 error.details；
5. 命令作用于 live 还是 --changeset；
6. 证明实际变更或未变更的 canonical readback；
7. 如有 Work，给出 Work ID 与 terminal state；
8. 分开报告文档图与 CodeGraph readiness；
9. 从干净临时项目开始的最小复现；
10. 当前 cleanup、retry 或 rollback 是否安全。

“不能用”不足以定位问题。截图可以作为补充，但不能替代可复制的 JSON 与命令。

复现模板

### Expected

### Actual

### Environment

- LWC version:
- OS and architecture:
- Install channel:
- Scope and current directory:

### Reproduction

1.
2.
3.

### Structured error and canonical readback

### Recovery and cleanup status

优先使用虚构内容的隔离项目。如果缺陷必须依赖旧 Store 或 checkpoint，应只分享仍能触发同一 error code 的最小脱敏 fixture。

脱敏规则

发布前移除或替换：

• access token、cookie、password、private key 与环境变量值；
• 复现不需要的 Source 和 Page body；
• 客户姓名、邮箱、标识符与私有仓库路径；
• Agent provider request body 与隐藏推理；
• 含凭据的转换参数；
• 可以用最小受管 fragment 说明问题时，不要贴完整宿主配置。

应保留真正影响问题的结构信息：路径形态、字节大小、文件类型、scope、error code、version 与顺序。明确说明哪些内容做过替换，避免维护者把占位符当成真实输入。

Agent 集成反馈

写明准确的 target 与 location，例如 codex/global 或 copilot-vscode/local。附上 install、status 与 refresh 结果，以及出现矛盾的能力模式。

官方返回 user_managed、configured_preview 或 unsupported 本身不代表缺陷。只有 LWC 写入无文档依据的宿主 surface、错误报告支持程度、破坏外部内容，或无法完成当前官方文档明确支持的能力时，才应按缺陷反馈。

不能把 AMC、维护者私有 HOME、local plugin cache 或私有 lwc binary 绝对路径当成公共环境要求。

图与检索反馈

文档图缺陷应附 graph status、graph verify 与准确节点标识。CodeGraph 问题应附 cg status，并区分 runtime 是否安装与项目索引是否初始化。

检索缺陷需要提供最小 Source/Page 集、固定 query、--explain 输出、预期 Page 和排序要求。看到结果后不能再修改 query。

Word Graph 问题应包括 query term、分页参数、返回的 request_limits，并说明属于数据缺失、密度过高还是渲染问题。

功能请求

应描述实际工作，而不只是建议一个命令。至少说明：

• 谁会遇到问题，频率如何；
• 为什么现有 search、tag、graph、changeset 或 Agent integration 无法解决；
• 最小可用行为；
• 安全、兼容和性能边界；
• 验收证据；
• 涉及外部 Agent 或 protocol surface 时，附当前官方文档。

不要先设计抽象通用框架。一个反复出现的具体工作流，比“以后可能需要扩展”更有说服力。

修复后

使用修复后的构建重新执行原复现，重复规范状态读取，等待所有 Work，并完成相关 lint、检索、图、Viewer 或 Agent 验收。只有原始失败路径真正通过，而不只是相邻单元测试通过时，才关闭 issue。

先阅读故障排查与常见问题，恢复流程参见维护与诊断。