请遵循以下有关插件设计的指南，提升用户的整体体验。
一般最佳实践
建议您为开发的所有插件采用以下最佳实践。
在开始之前确定插件所有权
插件由 Apps 脚本项目定义，这些项目必须归特定账号所有，否则必须放置在共享云端硬盘中。在编写插件代码之前，请确定哪个账号应拥有该项目，以及哪个账号应作为其发布商。还要确定哪些账号将作为协作者，并确保这些账号有权访问脚本项目及其关联的 Google 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 加载项和 Card 服务的使用。
仅使用少量卡片
如果插件使用的卡片过多，导航配置会变得复杂且难以管理。
避免创建超出必要数量的卡片。
使用 widget 创建函数
在编写用于创建 Card 或其他复杂界面对象的代码时，请考虑将该代码放在自己的函数中。此创建函数应仅构建对象并返回该对象。这样，您就可以在每次需要刷新界面时快速重新生成该对象。请记得在使用 Card 服务中的构建器类后调用 build()。
保持卡片简洁明了
如果某个卡片包含的小组件过多，可能会占据过多的屏幕空间，从而降低实用性。虽然大型卡片部分会呈现为可折叠的界面元素，但这会向用户隐藏信息。力求简化插件，只提供用户需要的，不多也不少。
使用错误卡片
为错误情况创建卡片。如果您的插件产生错误，它应该会显示一张卡片，其中包含错误信息以及有关如何更正错误的说明（如果可能）。例如，如果您的插件因授权失败而无法连接到非 Google 服务，请显示一张说明此情况的卡片，并要求用户验证所用的账号信息。
编写测试和测试消息
您应全面测试自己创建的所有插件。构建使用测试数据创建卡片和 widget 的测试函数，然后验证对象是否按预期创建。
使用操作回调函数时，通常必须构造一个响应对象。您可以使用如下语句来验证响应是否正在正确构建：
Logger.log(response.printJson());
使用 Run 菜单直接从 Apps 脚本编辑器运行您创建的测试函数。当您有可行的插件在运行后，请务必安装未发布的版本，以便进行测试。
使用适合插件所扩展的每个宿主应用的测试数据。例如，如果该插件扩展了 Gmail，您可能需要一些测试电子邮件及其消息 ID，以便确保该插件在获得不同的消息内容时能够按预期运行。您可以使用 Gmail API users.messages.list 方法列出消息，或利用 Apps 脚本的 Gmail 服务来获取指定消息的消息 ID。
日历会议最佳实践
如果您的插件将第三方日历会议选项集成到 Google 日历中，请遵循以下额外的最佳实践：
保持 onCreateFunction 光线
用户尝试创建相应类型的会议解决方案时，系统会同步调用您在清单中定义的每个 onCreateFunction。请确保这些函数仅执行创建会议所需的最低限度的工作。在这些函数中执行过多的操作可能会导致插件的用户体验不佳。
为会议数据使用适当的 ConferenceData 字段
构建 ConferenceData 对象时，您可以使用会议的详细信息（访问代码、电话号码、PIN 码、URI 等）填充这些对象。请务必使用相应的 EntryPoint 字段来提供此信息。请勿将这些详细信息放在 ConferenceData 备注字段中。
不将会议详细信息附加到 Google 日历活动
插件无需将有关创建的第三方会议的信息添加到 Google 日历活动说明中。Google 日历会在必要时自动执行此操作。