后端協(xié)同辦公WebSocket前端富文本【免費下載鏈接】etherpadEtherpad: A modern really-real-time collaborative document editor.項目地址https://gitcode.com/gh_mirrors/et/etherpad點擊查看免費下載Etherpad 是一個真正實時的協(xié)作文檔編輯器其核心core倉庫維護著 HTTP API、socket.io 握手/消息序列以及 changeset/attribpool 線纜wire格式。本篇文章圍繞核心倉庫中 Phase 1 實現(xiàn)計劃實現(xiàn)計劃與配套設計文檔完整講解如何在核心側(cè)搭建一套兼容性門禁通過黃金向量golden vectors、socket 消息序列、HTTP API 形狀三類契約測試Layer A以及能夠真實啟動服務器、按清單跑下游客戶端的 smoke 工作流Layer B讓任何針對develop的 PR 在合并前就發(fā)現(xiàn)會破壞獨立下游客戶端的變更。讀完本文你將掌握vectors:gen夾具生成機制、三類契約測試的編寫范式、clients.json清單與downstream-smoke.yml工作流的設計思路以及 Phase 1/Phase 2 的漸進式落地方法。背景下游客戶端為何會被靜默破壞Etherpad 的實時協(xié)作協(xié)議并非只有官方前端在使用。倉庫設計文檔明確指出當前有三個獨立倉庫的下游客戶端它們不是把 core 作為庫導入而是各自實現(xiàn)了或拷貝了線纜協(xié)議etherpad-cli-clientNode/TS 命令行客戶端自帶Changeset.tsAttributePool.ts的拷貝并自行與 socket.iomessage協(xié)議對話此前沒有測試腳本etherpad-padRust 終端編輯器在其etherpad-clientcrate 中手寫 engine.io v4 / socket.io v4 與 changeset 解碼已有 CI 與mock-socket測試特性etherpad-desktopElectron 桌面 Capacitor 移動端包裝/指向 core 服務器 URL已有 vitest Playwright e2e CI。問題在于這些客戶端的 CI 永遠不會針對新版 core 運行。當 core 的 PR 改動 HTTP API 響應形狀、socket.io 握手或message序列、changeset/attribpool 線纜格式時破壞是靜默的——core 自己測試全綠合并后下游客戶端才報錯。這正是該兼容性門禁要解決的痛點讓 coredevelop及其它分支上的 PR 在合并前就能探測到下游破壞。整體架構兩層兼容性門禁設計文檔將門禁設計為兩層跑在每一次 core PR 上core PR ──┬─? Layer A: Contract tests封閉、快速、無網(wǎng)絡/客戶端依賴 │ ? golden-vector 斷言changeset/attribpool 往返 │ ? socket.io 消息序列測試CLIENT_VARS、USER_CHANGES → ACCEPT_COMMIT │ ? HTTP API 形狀快照 │ └─? Layer B: Downstream smoke啟動真實服務器運行真實客戶端 ? 從 PR 構建并啟動 Etherpad:9003已知 API key ? 健康檢查輪詢直到就緒 ? 按 manifest 展開矩陣克隆客戶端 固定 ref搭建工具鏈 注入 core 新生成的 vectors運行客戶端 test:vectors 再運行客戶端 smoke連接 → 創(chuàng)建/打開 pad → 寫入文本 → 經(jīng) HTTP API 讀回 → 斷言一致 ? 按 PID 拆除服務器關鍵決策在設計階段已鎖定決策點選擇檢測策略混合式core 內(nèi)快速契約測試每個 PR 下游 smoke每個 PRsmoke 節(jié)奏每個 PR帶強防抖動措施CI 如何獲取客戶端在固定 ref 上 git clone記錄在 core 的 manifest 中契約深度共享黃金向量——core 生成規(guī)范夾具各客戶端用自研解碼器解碼同一夾具時序按層分階段——Phase 1 全部在 core 側(cè)Phase 2 逐個客戶端倉庫落地其中共享黃金向量是精髓core 用自己的Changeset/AttributePool引擎生成規(guī)范夾具每個客戶端必須用自己的重寫的解碼器產(chǎn)出相同結果。任何一邊的線纜實現(xiàn)漂移都會暴露。倉庫中的實際落地狀態(tài)需要說明的是本文對應的實現(xiàn)計劃在倉庫中已經(jīng)落地。計劃中規(guī)劃的 7 個新文件在當前倉庫中均可找到且個別文件與計劃初稿存在有意的差異后文會逐一點出生成器模塊已提交的黃金夾具夾具穩(wěn)定性測試socket 消息序列測試HTTP API 形狀測試客戶端清單下游 smoke 工作流額外還有 Phase 2 才規(guī)劃的 run-clients.sh 驅(qū)動腳本Task 1~3黃金向量生成器、夾具提交與穩(wěn)定性門禁生成器模塊線纜夾具的唯一事實來源計劃的第一步是創(chuàng)建 generate-vectors.ts。它是一個純模塊導出generateVectors(): WireVector[]作為規(guī)范線纜夾具的單一事實來源同時可作為 CLI 運行用于重新寫夾具文件。倉庫中實際實現(xiàn)的完整代碼use strict; import * as Changeset from ../../../../static/js/Changeset; import AttributePool from ../../../../static/js/AttributePool; export type WireVector { name: string; initialText: string; changeset: string; pool: ReturnTypeAttributePool[toJsonable]; resultText: string; }; const vector ( name: string, initialText: string, build: (pool: AttributePool) string, ): WireVector { const pool new AttributePool(); const changeset build(pool); Changeset.checkRep(changeset); return { name, initialText, changeset, pool: pool.toJsonable(), resultText: Changeset.applyToText(changeset, initialText), }; }; export const generateVectors (): WireVector[] [ vector(plain-insert, abc\n, () Changeset.makeSplice(abc\n, 3, 0, XYZ)), vector(plain-delete, abcdef\n, () Changeset.makeSplice(abcdef\n, 1, 3, )), vector(formatted-insert, abc\n, (pool) Changeset.makeSplice(abc\n, 3, 0, bold, [[bold, true]], pool)), vector(multiline-insert, abc\n, () Changeset.makeSplice(abc\n, 3, 0, one\ntwo\n)), vector(attrib-reuse, abc\n, (pool) { // Two formatted inserts sharing one pool entry exercises pool index reuse. const cs1 Changeset.makeSplice(abc\n, 0, 0, A, [[bold, true]], pool); const mid Changeset.applyToText(cs1, abc\n); const cs2 Changeset.makeSplice(mid, mid.length - 1, 0, B, [[bold, true]], pool); return Changeset.compose(cs1, cs2, pool); }), ]; // CLI entry: write the canonical fixture to disk. if (require.main module) { // eslint-disable-next-line typescript-eslint/no-var-requires const fs require(fs); // eslint-disable-next-line typescript-eslint/no-var-requires const path require(path); const out path.join(__dirname, ../../../fixtures/wire-vectors.json); fs.mkdirSync(path.dirname(out), {recursive: true}); fs.writeFileSync(out, ${JSON.stringify(generateVectors(), null, 2)}\n); // eslint-disable-next-line no-console console.log(wrote ${out}); }理解這段代碼的關鍵點向量自包含每個向量給定initialText與pool應用changeset后得到resultText。下游客戶端重新實現(xiàn)了 changeset/attribpool 解碼器消費完全相同的 JSON必須復現(xiàn)resultText。用 core 自己的引擎生成Changeset.makeSplice構造變更集、Changeset.compose合并兩個變更集attrib-reuse場景、Changeset.checkRep校驗不變式、Changeset.applyToText計算結果。這保證了夾具永遠與 core 當前序列化語義一致。覆蓋五類操作純插入、純刪除、帶屬性format/attrib的插入、多行插入char_bank以\n結尾、跨操作復用 attribpool 索引——正好覆蓋客戶端必須解碼的全部操作類別。注冊vectors:gen腳本在 src/package.json 的scripts中與既有test條目并列加入生成腳本。倉庫中實際值計劃初稿為tsx ...落地后為node --require tsx/cjs ...功能等價vectors:gen: node --require tsx/cjs tests/backend/specs/downstream/generate-vectors.ts,從src/目錄運行cd src pnpm run vectors:gen預期輸出wrote .../src/tests/fixtures/wire-vectors.json且文件包含 5 個向量逐個確認changeset非空、resultText與initialText不同。已提交的黃金夾具運行生成器后倉庫中實際提交的 wire-vectors.json 長這樣完整 5 條絕不手改[ { name: plain-insert, initialText: abc\n, changeset: Z:4333$XYZ, pool: { numToAttrib: {}, nextNum: 0 }, resultText: abcXYZ\n }, { name: plain-delete, initialText: abcdef\n, changeset: Z:731-3$, pool: { numToAttrib: {}, nextNum: 0 }, resultText: aef\n }, { name: formatted-insert, initialText: abc\n, changeset: Z:443*04$bold, pool: { numToAttrib: { 0: [bold, true] }, nextNum: 1 }, resultText: abcbold\n }, { name: multiline-insert, initialText: abc\n, changeset: Z:483|28$one\ntwo\n, pool: { numToAttrib: {}, nextNum: 0 }, resultText: abcone\ntwo\n\n }, { name: attrib-reuse, initialText: abc\n, changeset: Z:42*013*01$AB, pool: { numToAttrib: { 0: [bold, true] }, nextNum: 1 }, resultText: AabcB\n } ]眼檢要點數(shù)組共 5 個對象鍵為name, initialText, changeset, pool, resultTextplain-insert/plain-delete/multiline-insert的pool.numToAttrib為空formatted-insert與attrib-reuse含bold,true條目。值得注意attrib-reuse的結果兩個帶bold屬性的插入共享同一個池索引0生成AabcB\n這正是池索引復用語義的實證。夾具穩(wěn)定性 自洽性測試wire-vectors.ts 守衛(wèi)線纜格式契約包含兩條斷言use strict; const assert require(assert).strict; import fs from fs; import path from path; import * as Changeset from ../../../../static/js/Changeset; import {generateVectors} from ./generate-vectors; const fixturePath path.join(__dirname, ../../../fixtures/wire-vectors.json); describe(__filename, function () { it(committed fixture matches a fresh regeneration, function () { const committed JSON.parse(fs.readFileSync(fixturePath, utf8)); const fresh generateVectors(); assert.deepEqual(committed, fresh, wire-vectors.json is stale — run pnpm run vectors:gen and commit the result); }); it(every vector applies to its result under core Changeset, function () { for (const v of generateVectors()) { Changeset.checkRep(v.changeset); assert.equal(Changeset.applyToText(v.changeset, v.initialText), v.resultText, vector ${v.name} result mismatch); } }); });運行從src/cd src pnpm exec mocha --importtsx --timeout 120000 --extension ts tests/backend/specs/downstream/wire-vectors.ts預期 2 個用例通過。驗證門禁確實會咬人手工改一條wire-vectors.json中的resultText再運行committed fixture matches a fresh regeneration 用例會失敗——任何夾具漂移都必須是故意的線纜變更且必須在同一 PR 中重新生成并評審。測試通過后git checkout src/tests/fixtures/wire-vectors.json還原。這個穩(wěn)定性測試的深層價值在于當 core 未來修改 changeset 序列化時vectors:gen會生成不同的夾具 → 穩(wěn)定性用例失敗 → 提醒開發(fā)者這是破壞下游的線纜變更必須與下游客戶端協(xié)同升級。夾具漂移本身就是線纜發(fā)生了變化的信號。Task 4socket.io 消息序列測試wire-socket-sequence.ts 固定每個實時客戶端都依賴的 socket.io 消息序列與形狀握手handshake→CLIENT_VARS隨后USER_CHANGES→ACCEPT_COMMIT。Rust 終端編輯器與 Node CLI 都是手寫該序列的這里的任何改動都是會破壞下游的線纜協(xié)議變更。倉庫中實際實現(xiàn)與計劃初稿有一處重要差異初稿用common.waitForSocketEvent手工拼接屬性池落地版本改用后端套件現(xiàn)成的common.waitForAcceptCommit與common.sendUserChanges輔助函數(shù)并在注釋中明確了關鍵約束——插入操作必須攜帶會話作者屬性*0N 對應 apool 條目否則服務端會以{disconnect:badChangeset}拒絕use strict; const assert require(assert).strict; const common require(../../common); const padManager require(../../../../node/db/PadManager); describe(__filename, function () { let agent: any; let socket: any; let pad: any; let padId: string; before(async function () { agent await common.init(); }); beforeEach(async function () { padId common.randomString(); pad await padManager.getPad(padId, dummy\n); await pad.setText(\n); // ensure the pad exists at a known empty state const res await agent.get(/p/${padId}).expect(200); socket await common.connect(res); }); afterEach(async function () { if (socket ! null) socket.close(); socket null; if (pad ! null) await pad.remove(); pad null; }); it(handshake returns CLIENT_VARS with the client-facing shape, async function () { const {type, data} await common.handshake(socket, padId); assert.equal(type, CLIENT_VARS); assert.ok(data.userId, CLIENT_VARS.userId missing); assert.ok(data.collab_client_vars, collab_client_vars missing); assert.equal(typeof data.collab_client_vars.rev, number); assert.ok(data.collab_client_vars.initialAttributedText, collab_client_vars.initialAttributedText missing); }); it(USER_CHANGES is acknowledged with ACCEPT_COMMIT and a bumped rev, async function () { const {data: clientVars} await common.handshake(socket, padId); const rev clientVars.collab_client_vars.rev; const authorId clientVars.userId; // Insert ops must carry the session author attribute (*0N matching // apool entry) or the server rejects with {disconnect:badChangeset}. const apool {numToAttrib: {0: [author, authorId]}, nextNum: 1}; await Promise.all([ common.waitForAcceptCommit(socket, rev 1), common.sendUserChanges(socket, {baseRev: rev, changeset: Z:15*05$hello, apool}), ]); assert.equal(pad.text(), hello\n); }); });測試要點復用src/tests/backend/common.ts中的common.init()、common.connect(res)、common.handshake(socket, padId)等既有后端測試輔助函數(shù)以及src/tests/backend/specs/messages.ts模式第一個用例鎖定CLIENT_VARS形狀必須有userId、collab_client_vars且rev是 number、initialAttributedText存在第二個用例做真實的雙向確認發(fā)送USER_CHANGES變更集這里手寫線纜字符串Z:15*05$hello含作者屬性等待ACCEPT_COMMIT且newRev rev 1最后從 Pad 模型斷言文本確實是hello\n。運行命令cd src pnpm exec mocha --importtsx --timeout 120000 --extension ts tests/backend/specs/downstream/wire-socket-sequence.ts預期 2 個用例通過。計劃還給出防抖提示若waitForSocketEvent默認 1 秒超時對ACCEPT_COMMIT過緊可向其第 3 個參數(shù)傳更大的timeoutMs例如common.waitForSocketEvent(socket, message, 5000)。Task 5HTTP API 形狀快照wire-http-api.ts 快照下游客戶端調(diào)用端點創(chuàng)建 pad、往返文本的響應形狀鍵與類型而非易變的具體值。與計劃初稿基于common.apiKey的 GETapikey 查詢串不同落地版本改用與套件其余 api specs 一致的 JWT 認證common.generateJWTToken()參見 api/createDiffHTML.ts 一類的既有 specsetText用 POST JSON bodyuse strict; const assert require(assert).strict; const common require(../../common); describe(__filename, function () { let agent: any; let apiVersion 1; const padId wireHttp_${common.randomString()}; const endPoint (point: string) /api/${apiVersion}/${point}; before(async function () { agent await common.init(); const res await agent.get(/api/).expect(200).expect(Content-Type, /json/); apiVersion res.body.currentVersion; assert(apiVersion); }); it(createPad returns the standard {code,data,message} envelope, async function () { const res await agent.get(${endPoint(createPad)}?padID${padId}texthello%0A) .set(Authorization, await common.generateJWTToken()) .expect(200); assert.deepEqual(Object.keys(res.body).sort(), [code, data, message]); assert.equal(res.body.code, 0); }); it(setText getText round-trips text through the documented shape, async function () { await agent.post(endPoint(setText)) .set(Authorization, await common.generateJWTToken()) .send({padID: padId, text: world\n}) .expect(200); const res await agent.get(${endPoint(getText)}?padID${padId}) .set(Authorization, await common.generateJWTToken()) .expect(200); assert.equal(res.body.code, 0); assert.equal(typeof res.body.data.text, string); assert.equal(res.body.data.text, world\n); }); it(getRevisionsCount exposes a numeric revisions field, async function () { const res await agent.get(${endPoint(getRevisionsCount)}?padID${padId}) .set(Authorization, await common.generateJWTToken()) .expect(200); assert.equal(res.body.code, 0); assert.equal(typeof res.body.data.revisions, number); }); });三個用例分別鎖定createPad的標準{code, data, message}信封鍵集合排序后完全一致、code 0setTextgetText的文本往返data.text為 string 且精確等于world\ngetRevisionsCount暴露數(shù)值型revisions字段。apiVersion不是硬編碼而是啟動時從/api/響應的currentVersion動態(tài)讀取——這是對下游客戶端跟隨 API 版本演進行為的真實模擬。運行命令cd src pnpm exec mocha --importtsx --timeout 120000 --extension ts tests/backend/specs/downstream/wire-http-api.ts預期 3 個用例通過。Task 6客戶端清單manifestclients.json 是下游客戶端的注冊清單純數(shù)據(jù)。設計文檔強調(diào)ref 固定到具體 commit SHA 而非main這樣客戶端自己推代碼不會隨機染紅 core CI——提升某個 ref 必須是刻意的 PR。倉庫中實際落地時三個客戶端均已被點亮enabled: true說明 Phase 2 的對應 smoke 已經(jīng)落地與計劃初稿全部enabled:false的狀態(tài)不同[ { name: etherpad-pad, repo: https://github.com/ether/pad.git, ref: 91620c67c49536bb77e90b39f298ea70ae93c4a0, kind: rust, enabled: true, vectorTest: cargo test --test vectors, smokeCmd: cargo test --test smoke -- --ignored }, { name: etherpad-cli-client, repo: https://github.com/ether/etherpad-cli-client.git, ref: ebc516ef1a4e7a0c97ccd7a3f2db65e99f8e177c, kind: node, enabled: true, vectorTest: pnpm run test:vectors, smokeCmd: pnpm run test:smoke }, { name: etherpad-desktop, repo: https://github.com/ether/etherpad-desktop.git, ref: ab83da645b8683afbbc203e4a3fa6f3622a55709, kind: desktop, enabled: true, vectorTest: pnpm run test:vectors, smokeCmd: pnpm run test:smoke } ]字段語義name/repo/ref客戶端標識、倉庫地址、固定 commit SHAkindrust|node|desktop決定工作流為其準備的工具鏈Rust 工具鏈 / nodepnpm / 桌面 headless 運行方式enabledPhase 2 中某客戶端 smoke 落地后才翻轉(zhuǎn)為truevectorTest/smokeCmd該客戶端在注入夾具后要運行的向量測試與冒煙測試命令manifest 命令被視為倉庫內(nèi)可信白名單交由bash -euo pipefail -c執(zhí)行而非eval。驗證清單為合法 JSON 并打印概覽node -e const crequire(./src/tests/downstream/clients.json); console.log(c.length, c.map(xx.name).join(,))Task 7downstream-smoke 工作流downstream-smoke.yml 是 Layer B 的骨架啟動真實 Etherpad、健康檢查、自檢、拆除、并按清單展開客戶端矩陣。觸發(fā)條件為pull_request對doc/**、docs/**的純文檔改動忽略 每天 04:00 針對默認分支的schedule定時任務permissions: contents: read最小化權限。落地版工作流比計劃初稿更成熟關鍵差異點端口與認證的配置改寫計劃初稿假設直接設PORT9003 pnpm run prod落地版發(fā)現(xiàn)settings.json.template自帶字面量port: 9001與 sso 認證因此用sed將其改寫為 9003 與 apikey并用grep校驗改寫確實生效防模板格式漂移導致 sed 靜默空轉(zhuǎn)隨后把 API key 寫入APIKEY.txt健康檢查60 次 × 2 秒輪詢http://localhost:9003/api/超時則輸出服務日志并失敗自檢用 curl 完成一次帶認證的createPadgetText往返并grep斷言code:0與text:hi證明啟動→健康→自檢閉環(huán)可用向量生成cd src pnpm run vectors:gen確保注入給客戶端的夾具來自當前 PR的序列化客戶端矩陣通過bash src/tests/downstream/run-clients.sh執(zhí)行環(huán)境變量SMOKE_URL/SMOKE_APIKEY傳入按 PID 拆除if: always()保證無論成敗都執(zhí)行只kill記錄的 PID絕不pkill -f那會誤殺開發(fā)者機器上的其它服務器。倉庫中實際的 Boot 步驟供對照- name: Boot Etherpad on :9003 (apikey auth) run: | # The template ships a literal port: 9001 and sso auth; rewrite both. # (PORT env is ignored once the settings file specifies a port.) sed -e s#port: 9001,#port: 9003,# \ -e s#${AUTHENTICATION_METHOD:sso}#apikey# \ settings.json.template settings.json grep -q port: 9003, settings.json \ || { echo ::error::port rewrite failed — settings.json.template format changed; exit 1; } grep -q authenticationMethod: apikey settings.json \ || { echo ::error::auth rewrite failed — settings.json.template format changed; exit 1; } printf %s $APIKEY APIKEY.txt pnpm run prod /tmp/ep.log 21 echo $! /tmp/ep.pid echo booted pid $(cat /tmp/ep.pid)Phase 2 的驅(qū)動腳本run-clients.sh雖然計劃把按客戶端展開矩陣放在 Phase 2倉庫中 run-clients.sh 已經(jīng)實現(xiàn)了完整邏輯是理解clients.json消費方式的最佳源碼讀取 manifestfilter(x x.enabled)得到待運行列表輸出 TSV環(huán)境變量注入ETHERPAD_WIRE_VECTORS絕對路徑指向 core 剛生成的夾具讓客戶端測試當前 core 的序列化而非其自帶的舊快照、ETHERPAD_SMOKE_URL、ETHERPAD_SMOKE_APIKEY對每個客戶端git clone→ 若固定 SHA 不可達則fetch origin sha→checkout ref按kind分派rust直接跑vectorTestsmokeCmdnode/desktop先pnpm install每個客戶端在一個受保護的子 shell 中執(zhí)行單客戶端失敗置fail1但循環(huán)繼續(xù)命令經(jīng)由bash -euo pipefail -c運行而非eval確保流水線階段失敗能浮出表面全部結束后以fail為退出碼匯總。Task 8全量后端套件運行與 PR 提交流程新 specs 放在specs/downstream/子目錄因此既有mocha ... --recursive tests/backend/specs的 glob 會零配置自動納入。按總是運行后端測試的倉庫規(guī)則以套件真實使用的 mocha 調(diào)用方式運行整個下游 spec 組cd src cross-env NODE_ENVproduction pnpm exec mocha --importtsx --timeout 120000 --extension ts --recursive tests/backend/specs/downstream預期tests/backend/specs/downstream/下全部通過3 個文件共 7 個用例。隨后確認夾具守衛(wèi)無回歸cd src pnpm run vectors:gen git diff --exit-code src/tests/fixtures/wire-vectors.json預期退出碼 0再生成結果與已提交夾具逐字節(jié)一致。最后推送分支并創(chuàng)建 PR示意請按倉庫實際分支名調(diào)整git push -u origin feat/downstream-client-compat-tests gh pr create --base develop \ --title test: downstream client compatibility gate (Phase 1) \ --body Adds core-side contract tests (golden wire-vectors, socket-sequence, HTTP API shapes) and a downstream-smoke workflow scaffold... gh pr checks --watch防抖動設計smoke 每個 PR 都跑必須穩(wěn)設計文檔專門列出了防抖動措施工作流中均已體現(xiàn)健康檢查輪詢帶超時任何客戶端運行前先確認服務器就緒每個客戶端 smoke 有界超時 1 次重試桌面端保持 headless-light重的 Electron e2e 留在 desktop 自己倉庫不進 core 門禁若必須用 Electron 則置于xvfb-run下PID 式拆除絕不pkill -fmanifest ref 固定core CI 與客戶端自身破壞隔離提升 ref 是刻意的 PR端口固定 :90039001 保留給本地臨時使用避免端口沖突。分階段規(guī)劃與成功標準Phase 1core 側(cè)先落地、立即可用向量生成器 wire-vectors.json 三個契約 spec downstream-smoke.ymlclients.json清單先用一個已有測試基礎設施的參考客戶端Rustetherpad-pad驗證整套裝置——當前倉庫已處在此階段完成、Phase 2 部分推進的狀態(tài)Phase 2逐個客戶端倉庫推進按etherpad-pad→etherpad-cli-client→etherpad-desktop順序每個 PR 為該客戶端補上test:vectors smoke 并在 core manifest 中注冊翻enabled為 true。明確不在范圍內(nèi)的內(nèi)容不替換客戶端既有的完整 e2e 套件留在各自倉庫ep_kaput 按長期約定被排除不修改線纜協(xié)議本身——這套工作只觀察它。成功標準來自設計文檔改動 changeset 序列化、socket 消息序列或客戶端可見 API 形狀的 core PR在合并前必須觸發(fā) Layer A契約和/或 Layer Bsmoke失敗Phase 1 在 coredevelop上全綠落地Rust 客戶端接入 smoke 矩陣提升某客戶端的固定 ref是客戶端自身變更影響 core CI 的唯一途徑。總結這套 Phase 1 兼容性門禁回答了 Etherpad 生態(tài)的一個結構性難題當協(xié)議核心與消費方分屬不同倉庫時如何低成本地持續(xù)守護線纜契約。核心思路有三層黃金向量把 changeset/attribpool 線纜格式固化為可提交、可對比、可注入的 JSON 夾具socket 序列與 HTTP 形狀測試把實時與 REST 兩條通路的關鍵形狀釘死在每個 PR 上manifest smoke 工作流則保留了一條啟動真實服務器、運行真實客戶端的端到端退路并且通過固定 ref、PID 拆除、健康檢查輪詢等手段保證它不成為新的不穩(wěn)定源。若你需要為其它協(xié)議核心 獨立客戶端形態(tài)的項目搭建同類門禁本文的 8 個任務、防抖動清單與enabled漸進開關可以直接作為模板復用。贊分享后端協(xié)同辦公WebSocket前端富文本【免費下載鏈接】etherpadEtherpad: A modern really-real-time collaborative document editor.項目地址https://gitcode.com/gh_mirrors/et/etherpad點擊查看免費下載相關推薦Etherpad 下游客戶端兼容性測試設計為每個核心 PR 加裝雙層協(xié)議兼容閘門Etherpad 下游客戶端兼容性測試設計為每個核心 PR 加裝雙層協(xié)議兼容閘門 Etherpad 的核心倉庫 ether/etherpad 為獨立倉庫中后端協(xié)同辦公WebSocket前端富文本NSwag代碼生成契約測試確保客戶端與API兼容性NSwag代碼生成契約測試確?？蛻舳伺cAPI兼容性 在現(xiàn)代API開發(fā)中前后端分離架構已成為主流。但這種架構下客戶端與API服務端的接口契約一致性常常面臨挑開發(fā)工具代碼生成API設計claude-obsidian 貢獻工程契約與開發(fā)工作流測試隔離、契約校驗與驗證門禁實戰(zhàn)claude obsidian 貢獻工程契約與開發(fā)工作流測試隔離、契約校驗與驗證門禁實戰(zhàn) CONTRIBUTING.md 是 claude obsidianAI 技能知識庫知識管理RAG人工智能上一篇Gemma-4-E4B-it推理模式完全指南如何配置思維鏈獲得最佳輸出效果下一篇如何用PyTorch Serve快速部署Segment Anything Fast圖像分割模型完整實踐指南創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考