取得最佳成效的最佳做法
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
使用 Google Docs API 时,您应遵循以下几项原则。其中包括:
以下部分将介绍这些原则。
倒序剪辑以提高效率
在对 documents.batchUpdate
方法的单次调用中,按索引位置的降序对请求进行排序。这样就不需要计算因插入和删除而导致的索引更改。
协作规划
预期文档状态会发生变化。在一个方法调用和另一个方法调用之间,其他协作者可能会更新文档,如下图所示:

如果您的索引有误,这可能会导致错误。如果多个用户通过界面编辑文档,Google 文档会透明地处理此问题。不过,作为 API 客户端,您的应用必须管理此问题。即使您不打算与他人协作处理文档,也务必要采取防御性编程措施,确保文档状态保持一致。如需了解确保一致性的一种方法,请参阅 WriteControl
部分。
通过 WriteControl 建立状态一致性
当您读取并更新文档时,可以使用 documents.batchUpdate
方法中的 WriteControl
字段来控制如何处理竞争性更改。WriteControl
可控制写入请求的执行方式。
使用方法如下:
- 使用
documents.get
方法获取文档,并保存返回的 documents
资源中的 revisionId
。
- 撰写更新请求。
- 包含一个可选的
WriteControl
对象,其中包含以下两个选项之一:
requiredRevisionId
字段设置为写入请求所应用到的文档的 revisionId
。如果自 API 读取请求以来,文档已被修改,则写入请求不会被处理,并且会返回错误。
targetRevisionId
字段设置为写入请求所应用的文档的 revisionId
。如果文档自 API 读取请求以来已发生修改,则写入请求更改会根据协作者更改进行应用。写入请求的结果会将写入请求更改和协作者更改都纳入文档的新修订版本中。文档服务器负责合并内容。
如需查看如何使用 WriteControl
构建批量请求的示例,请参阅此批量请求示例。
考虑标签页
单个文档可以包含多个标签页,这些标签页需要在 API 请求中进行特殊处理。
请注意以下几点:
- 在
documents.get
方法中将 includeTabsContent
参数设置为 true
,以检索文档中所有标签页的内容。默认情况下,不会返回所有标签页内容。
- 在
documents.batchUpdate
方法中,指定要将每个 Request
应用到的标签页的 ID。每个 Request
都包含一种指定要应用更新的标签页的方法。默认情况下,如果未指定标签页,Request
在大多数情况下将应用于文档中的第一个标签页。如需了解具体信息,请参阅 Request
的文档。
如未另行说明,那么本页面中的内容已根据知识共享署名 4.0 许可获得了许可,并且代码示例已根据 Apache 2.0 许可获得了许可。有关详情,请参阅 Google 开发者网站政策。Java 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-08-29。
[null,null,["最后更新时间 (UTC):2025-08-29。"],[],[],null,["# Best practices for best results\n\nThere are several principles you should follow when using the Google Docs API.\nThese include:\n\n- Edit backwards for efficiency\n- Plan for collaboration\n- Ensure state consistency using the [`WriteControl`](/workspace/docs/api/reference/rest/v1/documents/batchUpdate#writecontrol) field\n- Take tabs into account\n\nThe following sections explain these principles.\n\nEdit backwards for efficiency\n-----------------------------\n\nWithin a single call to the\n[`documents.batchUpdate`](/workspace/docs/api/reference/rest/v1/documents/batchUpdate)\nmethod, order your requests in\n*descending order* of index location. This eliminates the need to compute the\nindex changes due to insertions and deletions.\n\nPlan for collaboration\n----------------------\n\nExpect the document state to change. Between one method call and another, other\ncollaborators might update the document, as shown in the following diagram:\n\nThis can lead to errors if your indexes are wrong. With multiple users editing a\ndocument using the UI, Google Docs takes care of this transparently. However,\nas an API client your app must manage this. Even if you don't anticipate\ncollaboration on the document, it's important to program defensively and make\nsure the document state remains consistent. For one way to ensure consistency,\nreview the [`WriteControl`](#establish-state-consistency) section.\n\nEstablish state consistency with WriteControl\n---------------------------------------------\n\nWhen you read and then update a document, you can control the behavior of how\ncompeting changes are handled using the\n[`WriteControl`](/workspace/docs/api/reference/rest/v1/documents/batchUpdate#writecontrol)\nfield in the `documents.batchUpdate` method. `WriteControl` provides authority\nover how write requests are executed.\n\nHere's how you use it:\n\n1. Get the document using the [`documents.get`](/workspace/docs/api/reference/rest/v1/documents/get) method and save the [`revisionId`](/workspace/docs/api/reference/rest/v1/documents#Document.FIELDS.revision_id) from the returned `documents` resource.\n2. Compose your update requests.\n3. Include an optional [`WriteControl`](/workspace/docs/api/reference/rest/v1/documents/batchUpdate#writecontrol) object with one of two options:\n 1. The `requiredRevisionId` field is set to the `revisionId` of the document the write request is applied to. If the document was modified since the API read request, the write request isn't processed and it returns an error.\n 2. The `targetRevisionId` field is set to the `revisionId` of the document the write request is applied to. If the document was modified since the API read request, the write request changes are applied against the collaborator changes. The result of the write request incorporates both the write request changes and the collaborator changes into a new revision of the document. The Docs server is responsible for merging the content.\n\nFor an example of how to construct a batch request using `WriteControl`, see\nthis [batch request example](/workspace/docs/api/how-tos/batch#example).\n\nTake tabs into account\n----------------------\n\nA single document can contain multiple [tabs](/workspace/docs/api/how-tos/tabs),\nwhich require specific handling in your API requests.\n\nHere's what to remember:\n\n1. Set the `includeTabsContent` parameter to `true` in the [`documents.get`](/workspace/docs/api/reference/rest/v1/documents/get) method to retrieve the content from all tabs in a document. By default, not all tab contents are returned.\n2. Specify the ID(s) of the tab(s) to apply each [`Request`](/workspace/docs/api/reference/rest/v1/documents/request#request) to in the [`documents.batchUpdate`](/workspace/docs/api/reference/rest/v1/documents/batchUpdate) method. Each [`Request`](/workspace/docs/api/reference/rest/v1/documents/request#request) includes a way to specify the tabs to apply the update to. By default, if a tab is not specified, the [`Request`](/workspace/docs/api/reference/rest/v1/documents/request#request) will in most cases be applied to the first tab in the document. Refer to the [`Request`](/workspace/docs/api/reference/rest/v1/documents/request#request)s documentation for specifics.\n\nRelated topics\n--------------\n\n- [Batch requests](/workspace/docs/api/how-tos/batch)\n- [Requests and responses](/workspace/docs/api/concepts/request-response)\n- [Work with tabs](/workspace/docs/api/how-tos/tabs)"]]