爭取最佳成效的最佳做法
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
使用 Google 文件 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
說明文件。
除非另有註明,否則本頁面中的內容是採用創用 CC 姓名標示 4.0 授權,程式碼範例則為阿帕契 2.0 授權。詳情請參閱《Google Developers 網站政策》。Java 是 Oracle 和/或其關聯企業的註冊商標。
上次更新時間:2025-08-29 (世界標準時間)。
[null,null,["上次更新時間: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)"]]