请遵循以下关于插件设计的指南，提升用户的整体体验。
一般最佳实践
我们建议您针对自己开发的所有插件遵循以下最佳实践。
在开始之前确定插件所有权
插件由 Apps Script 项目定义，这些项目必须归特定账号所有，或者放置在共享云端硬盘中。在编写插件代码之前，请确定哪个账号应拥有该项目，以及哪个账号应充当其发布商。此外，还要确定哪些账号将充当协作者，并确保这些账号有权访问脚本项目及其关联的 Cloud 平台项目。
扩展 Google Workspace，而不是复制它
插件旨在为其扩展的 Google Workspace 应用提供新功能，或者自动执行复杂任务。如果插件仅复制应用中已有的功能，或者未对工作流程进行显著改进，则不太可能通过插件审核并发布。
缩小范围
明确定义镜重范围时，请始终选择权限最小的镜重范围组合。例如，如果您的插件只需要读取权限，请勿让其使用 https://www.googleapis.com/auth/calendar 范围请求对用户日历的完整访问权限。对于只读访问权限，请使用 https://www.googleapis.com/auth/calendar.readonly 范围。
避免过度依赖库
与将所有 Apps 脚本代码包含在单个脚本项目中相比，使用 Apps 脚本库可能会导致您的插件运行速度变慢。虽然 Apps 脚本库在插件中可以正常运行，但如果您使用它们，可能会遇到性能下降的问题。避免在项目中添加不必要的库，并考虑减少插件对这些库的依赖。
上述延迟时间仅适用于用作服务器端库的 Apps 脚本项目。您可以自由使用 jQuery 等客户端 JavaScript 库，而不会遇到此延迟。
Google Workspace 插件最佳实践
以下最佳实践仅适用于 Google Workspace 插件和卡片服务的使用。
只需使用几张卡片
如果该插件使用了过多的卡片，导航配置会变得复杂且难以管理。
避免出于冲动而创建超出必要的卡片。
使用 widget 创建函数
编写用于创建 Card 或其他复杂界面对象的代码时，不妨考虑将该代码放入自己的函数中。此创建函数应仅构建对象并将其返回。这样，每当必须刷新界面时，您就可以快速重新生成该对象。请务必在 Card 服务中使用构建器类后调用 build()。
卡片应保持简洁
如果给定卡片包含的微件过多，则可能会占据屏幕太多空间，从而降低实用性。虽然大型卡片部分会呈现为可收起的界面元素，但这会向用户隐藏信息。应力求简化您的插件，并提供用户所需的功能，不提供多余的功能。
使用错误卡片
为错误情况创建卡片。如果您的插件产生错误，则应显示一个卡片，其中包含错误信息和有关如何更正错误的说明（如果可能）。例如，如果您的插件因授权失败而无法连接到非 Google 服务，请显示一条说明这一点的卡片，并要求用户验证所使用的账号信息。
编写测试和测试消息
您应对自己创建的所有插件进行全面测试。构建使用测试数据创建卡片和 widget 的测试函数，然后验证对象是否按预期创建。
使用操作回调函数时，您通常必须构造响应对象。您可以使用以下语句来验证响应是否构建正确：
Logger.log(response.printJson());
您可以直接在 Apps Script 编辑器中使用 Run 菜单运行自己创建的测试函数。当您拥有可正常运行的插件后，请务必安装未发布的版本，以便进行测试。
使用适用于该插件扩展的每个托管应用的测试数据。例如，如果该插件扩展了 Gmail，您可能需要一些测试电子邮件及其邮件 ID，以确保该插件在收到不同邮件内容时能按预期运行。您可以使用 Gmail API Users.messages.list 方法列出消息，或使用 Apps 脚本的 Gmail 服务来获取给定消息的消息 ID。
日历会议最佳实践
如果您的插件将第三方日历会议选项集成到 Google 日历中，请遵循以下其他最佳实践：
让您的 onCreateFunction 灯保持亮起状态
当用户尝试创建该类型的会议解决方案时，系统会同步调用您在清单中定义的每个 onCreateFunction。请确保这些函数仅执行创建会议所需的最低限度工作。在这些函数中执行过多操作可能会导致用户在使用您的插件时遇到速度缓慢的问题。
针对会议数据使用适当的 ConferenceData 字段
构建 ConferenceData 对象时，您可以使用与会议相关的详细信息（访问码、电话号码、PIN 码、URI 等）对其进行填充。请务必使用相应的 EntryPoint 字段来提供此信息。请勿在 ConferenceData 备注字段中添加这些详细信息。
不会将会议详情附加到 Google 日历活动
您的插件无需向 Google 日历活动说明中添加有关创建的第三方会议的信息。Google 日历会在必要时自动执行此操作。