提交 Zotero 插件与持续维护：收录、适配和反馈

插件发布之后，使用者还需要知道它做什么、适合哪个 Zotero 版本、去哪里下载，以及遇到问题该怎样联系维护者。把这些信息整理好，比一段夸张的宣传更有帮助。社区收录提供发现入口，不等于安全审计、官方认证或质量保证。

准备可查证的收录资料

提交前先阅读本站当前的收录与数据规则，再查看公开仓库说明的参与方式。当前规则要求在公开仓库新建 Issue，写清申请类型、插件资料与依据；更正信息时指出具体项目和字段，下架申请还需说明申请者与项目的关系。不要把第三方站点的表单当成本社区入口，具体要求以提交时的规则为准。

建议一次提供插件名称、原仓库链接、简短用途、维护者、可下载的发布版本、许可证和适配声明。用途写成具体任务，例如“为条目增加某种查看方式”，不要只写“科研神器”。截图用自己的测试资料，避免展示私人文献、账户或尚未公开的内容。商业条件、外部服务要求及数据去向也应在项目文档里说清楚。

最低版本和最高版本不只是展示文字。先看安装包声明，再用准备支持的版本实际验证。新大版本发布时，应检查官方开发者说明、核心工作流和退出清理，确认确实可用后再调整声明。无法验证的版本写“待验证”或不声明，不因界面能出现就认定全部功能兼容。

检查至少覆盖全新安装、已有版本升级、日常主要操作、禁用再启用，以及多窗口和深浅色等相关场景。涉及附件或批量数据时增加针对性样例，确认失败不会留下难以恢复的结果。维护者可以公开一张简短测试表，让使用者知道结论来自哪个系统和版本，而不是猜测。

在项目里放清楚的反馈入口。报告模板可以询问系统、Zotero 与插件版本、预期结果、实际结果及最短复现步骤。日志只索取排查所需部分，提醒使用者先检查个人信息。对“不能用了”这样的报告，先确认具体入口和现象，再请对方补足证据，不要求一开始就上传整个文库。

复现后注明影响范围，修复后邀请报告者在相同条件下验证。暂时不能处理时也可以说明状态与已知替代操作，不要让没有回复的讨论被误读为已经解决。长时间没有版本发布不必然等于停止维护；同样，频繁发布和很多星标也不能证明质量。

“插件已收录，为什么不能安装？”先核对 Zotero 版本、XPI 的适配范围及下载文件是否正确，收录本身不会改变安装条件。“下载次数就是用户数吗？”不是，重复下载、自动获取等都会影响次数，只能按公开下载口径解释。“可以申请置顶吗？”本站对所有插件使用同一规则，不设置置顶或推荐位。

如果项目暂停维护，明确写出最后测试的版本和已知限制，并说明是否接受接手维护；若项目地址迁移，尽量保留指向新地址的说明。持续维护不一定意味着不断增加功能，也包括准确记录现状、响应可复现问题，以及让使用者能够作出知情选择。