1. 從“上下文模式”說起一個被低估的工程概念第一次聽到“context-mode”這個詞很多人會以為是某個新出的框架或者庫。其實不是。它更像是一種設計思路一種在系統(tǒng)里管理“上下文”這件事的工程模式。你可以在前端狀態(tài)管理里見到它可以在后端請求鏈路里見到它也可以在大模型應用的會話管理里見到它。名字聽起來抽象但落到代碼上它解決的是一個非常具體的問題同一份邏輯在不同上下文環(huán)境下應該表現(xiàn)出不同但又可控的行為。我最早接觸這個概念是在做一個多租戶后臺系統(tǒng)的時候。當時的需求是同一套接口既要服務Web端又要服務移動端還要給內(nèi)部運營工具用。三端的字段需求、權限粒度、緩存策略都不一樣。如果每個端寫一套接口維護成本會爆炸如果全塞進一個接口用參數(shù)區(qū)分代碼會變成一堆if-else。后來我們引入了一個“上下文模式”的中間層把“當前請求處于什么上下文”這件事顯式建模后續(xù)所有邏輯都基于這個上下文做決策。代碼量減少了大概四成而且新增一個端只需要注冊一個新的上下文配置不用動核心邏輯。這就是context-mode的核心價值把隱式的環(huán)境判斷變成顯式的上下文對象讓行為分支變得可配置、可測試、可擴展。它適合誰呢如果你正在做多端適配、多租戶系統(tǒng)、A/B實驗、灰度發(fā)布、或者大模型應用里的多輪會話管理那context-mode這套思路你大概率用得上。哪怕你只是寫一個稍微復雜點的React組件需要根據(jù)父級環(huán)境改變渲染策略理解這個概念也能讓你的代碼更干凈。下面我會從設計思路、核心細節(jié)、實操落地、問題排查幾個層面把這件事講透。2. 內(nèi)容整體設計與思路拆解2.1 為什么需要顯式的上下文模式在沒有context-mode之前我們是怎么處理環(huán)境差異的最常見的就是傳參。函數(shù)簽名里加一個env或者platform參數(shù)然后內(nèi)部根據(jù)這個參數(shù)走不同分支。這種做法在簡單場景下沒問題但一旦分支超過三個代碼就開始失控。我見過一個接口函數(shù)有七個布爾參數(shù)調(diào)用方每次都要查文檔才知道該傳什么。這就是典型的“上下文爆炸”。另一種做法是用全局變量或者線程局部存儲。比如在請求入口處把當前用戶、租戶、設備信息塞進一個全局對象后續(xù)所有函數(shù)直接讀。這種做法寫起來爽但調(diào)試起來痛苦。你永遠不知道某個函數(shù)讀到的全局狀態(tài)是不是最新的測試的時候也沒法輕松模擬不同上下文。context-mode的思路介于兩者之間。它不把上下文藏在全局變量里也不把它拆成散落的參數(shù)而是把上下文封裝成一個不可變的對象在調(diào)用鏈的入口處創(chuàng)建然后顯式傳遞下去。這個對象通常包含幾個關鍵維度身份誰在請求、環(huán)境從哪來、配置該用什么策略、狀態(tài)當前處于什么階段。這樣做的第一個好處是可測試性。你想測試移動端的行為只需要構(gòu)造一個context { platform: mobile, ... }傳進去不需要改任何全局狀態(tài)。第二個好處是可追溯性。每個決策點都能追溯到是上下文的哪個字段導致了當前分支排查問題的時候一目了然。第三個好處是可擴展性。新增一個上下文維度只需要在上下文對象里加一個字段然后在決策點讀取它不需要改函數(shù)簽名。2.2 上下文模式與其他方案的對比為了讓你更清楚什么時候該用context-mode我把它和幾種常見方案做個對比。方案優(yōu)點缺點適用場景函數(shù)傳參簡單直接無額外抽象參數(shù)膨脹調(diào)用方負擔重分支少于3個的簡單場景全局變量寫起來快無需傳遞難測試難追蹤并發(fā)不安全單線程腳本、一次性任務依賴注入解耦徹底可替換容器配置復雜學習曲線陡大型應用、需要頻繁替換實現(xiàn)context-mode顯式、可測、可擴展需要設計上下文結(jié)構(gòu)有前期成本多端、多租戶、多階段流程從表里能看出來context-mode不是銀彈。如果你的系統(tǒng)只有一兩個環(huán)境差異直接傳參就夠了。但當你發(fā)現(xiàn)代碼里到處都在判斷“當前是不是移動端”“當前租戶有沒有開啟某個功能”“當前是不是灰度用戶”那就是時候把上下文抽出來了。我個人的經(jīng)驗是當同一個環(huán)境判斷在超過五個地方出現(xiàn)時就應該考慮context-mode。因為這時候你已經(jīng)有了隱式的上下文只是它散落在各處把它顯式化反而能降低認知負擔。2.3 上下文對象應該包含什么設計上下文對象是context-mode最關鍵的一步。設計得好后續(xù)擴展順滑設計得差用不了多久又要重構(gòu)。我總結(jié)了一個原則上下文只放“決策依據(jù)”不放“決策結(jié)果”。什么意思比如“當前用戶是不是VIP”這是一個決策依據(jù)應該放在上下文里。“當前用戶能不能看這個字段”這是一個決策結(jié)果不應該放在上下文里而應該由決策函數(shù)根據(jù)上下文計算出來。如果把決策結(jié)果也塞進上下文那上下文就會越來越臃腫最后變成一個什么都裝的垃圾袋。一個典型的上下文對象通常包含這幾類字段身份維度用戶ID、租戶ID、角色列表。這些字段決定了“誰在操作”影響權限和數(shù)據(jù)隔離。環(huán)境維度平臺類型Web/iOS/Android、客戶端版本、語言地區(qū)。這些字段決定了“從哪來”影響展示格式和功能開關。配置維度功能開關集合、實驗分組、限流閾值。這些字段決定了“該用什么策略”影響行為分支。流程維度當前步驟、重試次數(shù)、超時預算。這些字段決定了“處于什么階段”影響流程控制。注意這些字段都應該是不可變的。上下文一旦創(chuàng)建就不應該在傳遞過程中被修改。如果需要派生新的上下文應該創(chuàng)建一個新對象而不是改原來的。這樣做的好處是避免“上下文污染”——某個中間件改了上下文下游所有邏輯都受影響但調(diào)用方完全不知情。3. 核心細節(jié)解析與實操要點3.1 上下文的創(chuàng)建時機與傳遞方式上下文應該在什么時候創(chuàng)建答案是在系統(tǒng)邊界處。對于Web服務邊界就是HTTP請求進入的那一刻。對于前端應用邊界就是路由切換或者組件掛載的那一刻。對于大模型應用邊界就是一次會話開始的那一刻。創(chuàng)建之后怎么傳遞有兩種主流方式。一種是顯式參數(shù)傳遞每個函數(shù)都接收一個context參數(shù)。這種方式最清晰但代碼會變得啰嗦。另一種是隱式傳遞通過框架提供的機制比如React的Context、Python的contextvars、Go的context.Context在調(diào)用鏈中自動傳遞。這種方式寫起來簡潔但需要理解框架的傳遞規(guī)則。我一般建議核心業(yè)務邏輯用顯式傳遞框架層和工具函數(shù)用隱式傳遞。因為核心邏輯是決策發(fā)生的地方顯式傳遞能讓決策依據(jù)一目了然。而工具函數(shù)比如日志、序列化只是消費上下文隱式傳遞能減少噪音。以Python為例contextvars是標準庫提供的上下文變量機制它能在異步任務中正確隔離上下文。下面是一個簡化的示例import contextvars from dataclasses import dataclass dataclass(frozenTrue) class RequestContext: tenant_id: str platform: str feature_flags: frozenset user_role: str _current_context contextvars.ContextVar(current_context) def set_context(ctx: RequestContext): _current_context.set(ctx) def get_context() - RequestContext: return _current_context.get()在請求入口處調(diào)用set_context后續(xù)任何地方調(diào)用get_context都能拿到當前請求的上下文。注意RequestContext用了frozenTrue保證不可變。feature_flags用了frozenset也是不可變集合。這些細節(jié)看起來小但能防止很多意外修改。3.2 決策點的組織方式有了上下文之后下一步是在決策點消費它。決策點就是那些“根據(jù)上下文走不同分支”的地方。組織決策點的方式直接決定了代碼的可維護性。最差的方式是在業(yè)務邏輯里直接寫if context.platform mobile。這種方式的問題是決策邏輯和業(yè)務邏輯混在一起改一個策略要翻遍所有文件。好一點的方式是把決策邏輯抽成獨立的函數(shù)比如should_show_feature(context, feature_name)。更好的方式是用策略表或者規(guī)則引擎把決策邏輯配置化。我比較推薦的是策略表方式。具體做法是定義一個字典或者列表每一項描述“在什么上下文條件下執(zhí)行什么行為”。然后在決策點用一個統(tǒng)一的函數(shù)去匹配。這樣做的好處是新增策略只需要加一條配置不需要改代碼。FEATURE_RULES [ {feature: new_dashboard, platform: web, min_version: 2.0, enabled: True}, {feature: new_dashboard, platform: mobile, min_version: 3.0, enabled: True}, {feature: new_dashboard, platform: web, min_version: 0.0, enabled: False}, ] def is_feature_enabled(context, feature): for rule in FEATURE_RULES: if rule[feature] ! feature: continue if rule[platform] ! context.platform: continue if context.client_version rule[min_version]: continue return rule[enabled] return False這個例子里規(guī)則按優(yōu)先級排列第一條匹配的規(guī)則決定結(jié)果。新增一個平臺的支持只需要加一行配置。這種模式在功能開關、灰度發(fā)布、A/B實驗里特別常用。3.3 上下文的序列化與透傳在分布式系統(tǒng)里上下文往往需要跨服務傳遞。比如網(wǎng)關創(chuàng)建了上下文后面幾個微服務都要用。這時候就需要把上下文序列化到請求頭或者消息元數(shù)據(jù)里。序列化的時候要注意兩點。第一是體積控制。上下文里不要放太大的對象比如完整的用戶信息。只放決策必需的字段比如用戶ID和角色。需要詳細信息的時候下游服務自己查。第二是安全性。上下文里可能包含租戶ID、用戶ID這些敏感信息傳輸過程中要確保不被篡改。通常的做法是簽名或者加密但也要權衡性能開銷。透傳的時候要注意默認值處理。如果某個服務收到的請求里沒有上下文比如內(nèi)部調(diào)用忘了帶應該有一個合理的默認上下文而不是直接報錯。默認上下文通常是“最小權限”的比如匿名用戶、默認租戶、所有功能關閉。這樣即使透傳失敗系統(tǒng)也不會暴露不該暴露的數(shù)據(jù)。注意上下文透傳最容易出的問題是“部分透傳”。比如網(wǎng)關傳了租戶ID但沒傳平臺類型下游服務用默認平臺處理結(jié)果返回了錯誤的格式。建議在上下文創(chuàng)建時就做完整性校驗缺字段直接拒絕請求而不是讓下游猜。4. 實操過程與核心環(huán)節(jié)實現(xiàn)4.1 從零搭建一個上下文模式的原型光說理論不夠我?guī)阕咭槐橥暾拇罱ㄟ^程。假設我們要做一個內(nèi)容展示服務需要根據(jù)用戶所在平臺、租戶配置、用戶角色決定展示哪些字段、用什么格式、走什么緩存策略。第一步定義上下文結(jié)構(gòu)。我們用一個Python的dataclass來表示from dataclasses import dataclass, field from typing import FrozenSet dataclass(frozenTrue) class ContentContext: tenant_id: str user_id: str platform: str # web | mobile | api locale: str # zh-CN | en-US roles: FrozenSet[str] feature_flags: FrozenSet[str] client_version: str request_id: str這個結(jié)構(gòu)里tenant_id和user_id是身份維度platform和locale是環(huán)境維度roles和feature_flags是配置維度client_version和request_id是流程維度。所有字段都是不可變的。第二步在請求入口創(chuàng)建上下文。以FastAPI為例from fastapi import FastAPI, Request, HTTPException app FastAPI() app.middleware(http) async def create_context(request: Request, call_next): tenant_id request.headers.get(X-Tenant-Id) user_id request.headers.get(X-User-Id) platform request.headers.get(X-Platform, web) locale request.headers.get(X-Locale, zh-CN) client_version request.headers.get(X-Client-Version, 0.0) if not tenant_id or not user_id: raise HTTPException(status_code400, detailMissing identity headers) roles await fetch_user_roles(user_id, tenant_id) flags await fetch_tenant_flags(tenant_id) ctx ContentContext( tenant_idtenant_id, user_iduser_id, platformplatform, localelocale, rolesfrozenset(roles), feature_flagsfrozenset(flags), client_versionclient_version, request_idrequest.headers.get(X-Request-Id, str(uuid4())), ) set_context(ctx) response await call_next(request) return response這段中間件做了幾件事從請求頭提取上下文信息校驗必填字段查詢角色和功能開關構(gòu)造不可變上下文對象存入contextvars。后續(xù)所有處理函數(shù)都可以通過get_context()拿到它。第三步在業(yè)務邏輯里消費上下文。比如一個內(nèi)容組裝函數(shù)def build_content_response(content_id: str) - dict: ctx get_context() content load_content(content_id, ctx.tenant_id) fields select_fields(ctx) formatted format_content(content, ctx.locale, ctx.platform) cache_ttl compute_cache_ttl(ctx) return { data: {k: formatted[k] for k in fields}, meta: {request_id: ctx.request_id, cache_ttl: cache_ttl} } def select_fields(ctx: ContentContext) - list: base [id, title, summary] if editor in ctx.roles: base.extend([draft, internal_notes]) if premium_content in ctx.feature_flags: base.append(premium_body) if ctx.platform mobile: base [f for f in base if f ! internal_notes] return base注意select_fields這個函數(shù)它完全基于上下文做決策沒有任何全局狀態(tài)也沒有任何IO操作。這意味著它可以被單元測試輕松覆蓋構(gòu)造不同的上下文斷言返回的字段列表是否符合預期。4.2 參數(shù)計算與策略選擇過程上下文模式里經(jīng)常需要根據(jù)上下文計算一些參數(shù)比如緩存TTL、限流閾值、超時時間。這些計算過程最好也抽成純函數(shù)輸入是上下文輸出是參數(shù)值。以緩存TTL為例。我們的策略是VIP租戶緩存時間長一點移動端緩存時間短一點有草稿內(nèi)容的緩存時間最短。計算過程如下def compute_cache_ttl(ctx: ContentContext) - int: base_ttl 300 # 默認5分鐘 if vip in ctx.feature_flags: base_ttl 900 # VIP租戶15分鐘 if ctx.platform mobile: base_ttl min(base_ttl, 180) # 移動端最多3分鐘 if editor in ctx.roles: base_ttl min(base_ttl, 60) # 編輯角色最多1分鐘 return base_ttl這個函數(shù)的邏輯很直白先設默認值然后根據(jù)上下文逐條調(diào)整最后返回。每條調(diào)整都有明確的理由VIP租戶內(nèi)容變化少可以緩存久一點移動端網(wǎng)絡不穩(wěn)定緩存短一點能更快看到更新編輯角色需要頻繁看到最新內(nèi)容緩存最短。這種“默認值逐條調(diào)整”的模式在參數(shù)計算里很常用。它的好處是每條規(guī)則的意圖清晰新增規(guī)則只需要加一個if不會影響已有邏輯。而且因為函數(shù)是純的你可以寫一個表格來驗證各種上下文組合下的輸出場景feature_flagsplatformroles計算出的TTL普通Web用戶無webuser300VIP Web用戶vipwebuser900VIP移動用戶vipmobileuser180普通編輯無webeditor60VIP移動編輯vipmobileeditor60這種表格在代碼審查的時候特別有用 reviewer一眼就能看出策略是否符合預期。4.3 上下文的測試策略context-mode最大的好處之一就是可測試性。因為上下文是顯式傳入的你可以輕松構(gòu)造各種邊界情況。我通常會把測試分成三層。第一層是上下文構(gòu)造測試驗證從請求頭到上下文對象的轉(zhuǎn)換是否正確。第二層是決策函數(shù)測試驗證給定上下文時各個決策函數(shù)返回的結(jié)果是否符合預期。第三層是集成測試驗證整個請求鏈路在不同上下文下的行為。決策函數(shù)測試是最有價值的因為它們覆蓋了大部分業(yè)務規(guī)則。用pytest寫起來大概是這樣import pytest from myapp.context import ContentContext from myapp.decisions import select_fields, compute_cache_ttl def make_ctx(**overrides): defaults dict( tenant_idt1, user_idu1, platformweb, localezh-CN, rolesfrozenset([user]), feature_flagsfrozenset(), client_version1.0, request_idr1 ) defaults.update(overrides) return ContentContext(**defaults) def test_select_fields_base(): ctx make_ctx() assert select_fields(ctx) [id, title, summary] def test_select_fields_editor(): ctx make_ctx(rolesfrozenset([user, editor])) assert internal_notes in select_fields(ctx) def test_select_fields_mobile_excludes_internal(): ctx make_ctx(rolesfrozenset([editor]), platformmobile) assert internal_notes not in select_fields(ctx) def test_cache_ttl_vip_mobile(): ctx make_ctx(feature_flagsfrozenset([vip]), platformmobile) assert compute_cache_ttl(ctx) 180這種測試寫起來快跑起來也快而且覆蓋了各種組合。每次改決策邏輯跑一遍測試就知道有沒有破壞已有行為。這比手動點頁面驗證靠譜多了。實操心得我習慣在上下文對象里加一個request_id字段然后在日志里輸出它。這樣排查線上問題時可以通過request_id把一次請求的所有日志串起來包括它當時的上下文是什么。這個習慣幫我省了很多“為什么這個用戶看到了不該看的內(nèi)容”之類的排查時間。5. 常見問題與排查技巧實錄5.1 上下文丟失與默認值陷阱context-mode最常見的問題就是上下文丟失。表現(xiàn)是某個函數(shù)調(diào)用get_context()時拋異?；蛘吣玫搅艘粋€空的默認上下文。原因通常有三種。第一種是異步任務里沒有正確傳遞上下文。在Python里如果你用asyncio.create_task創(chuàng)建新任務contextvars默認會復制當前上下文但如果你在線程池里執(zhí)行上下文就不會自動傳遞。解決辦法是在提交任務時顯式捕獲上下文然后在任務內(nèi)部重新設置。import asyncio import contextvars def run_in_executor_with_context(executor, func, *args): ctx contextvars.copy_context() return executor.submit(ctx.run, func, *args)第二種是中間件順序問題。如果上下文中間件注冊在鑒權中間件之后那鑒權中間件里就拿不到上下文。解決辦法是確保上下文中間件是最早執(zhí)行的之一通常放在最外層。第三種是跨服務調(diào)用時忘了透傳。比如服務A調(diào)服務B只傳了業(yè)務參數(shù)沒傳上下文頭。服務B用默認上下文處理結(jié)果行為不對。解決辦法是在HTTP客戶端里統(tǒng)一注入上下文頭不要依賴每個調(diào)用方手動傳。默認值陷阱是另一個坑。有些團隊為了“容錯”給上下文缺失的情況設了很寬松的默認值比如默認租戶、默認管理員角色。結(jié)果一旦透傳失敗系統(tǒng)不但沒報錯反而用高權限處理了請求。這是很危險的。我的建議是默認上下文應該是“最小權限”的缺關鍵字段直接拒絕請求。寧可報錯不要靜默降級。5.2 上下文膨脹與性能問題上下文對象如果設計得太大會帶來兩個問題。一是序列化和透傳的開銷變大二是每次創(chuàng)建上下文都要查很多數(shù)據(jù)增加請求延遲。我見過一個系統(tǒng)上下文里塞了完整的用戶對象、租戶配置、權限樹、功能開關列表加起來有幾十KB。每次請求都要從數(shù)據(jù)庫查一遍然后序列化到請求頭里傳給下游。結(jié)果請求延遲里有一大半花在上下文處理上。解決辦法是懶加載緩存。上下文里只放ID和少量關鍵字段需要詳細信息時再按需查詢。查詢結(jié)果可以緩存在請求級別的緩存里避免重復查。比如class LazyContext: def __init__(self, tenant_id, user_id, ...): self._tenant_id tenant_id self._user_id user_id self._tenant_config None property def tenant_config(self): if self._tenant_config is None: self._tenant_config load_tenant_config(self._tenant_id) return self._tenant_config這樣上下文對象本身很小透傳成本低但需要詳細信息時又能拿到。注意這種懶加載的上下文不是嚴格不可變的因為內(nèi)部緩存會變。但對外表現(xiàn)仍然是只讀的可以接受。另一個性能問題是上下文創(chuàng)建時的查詢。如果每次請求都要查用戶角色和功能開關數(shù)據(jù)庫壓力會很大。解決辦法是加緩存比如用Redis緩存角色和開關TTL設短一點比如30秒平衡一致性和性能。5.3 常見問題速查表問題現(xiàn)象可能原因排查方法解決方案函數(shù)報“上下文未設置”異步任務未傳遞上下文檢查任務創(chuàng)建方式用copy_context顯式傳遞行為不符合預期上下文字段值不對打印上下文對象檢查中間件提取邏輯下游服務行為異常上下文未透傳檢查請求頭統(tǒng)一注入上下文頭請求延遲高上下文創(chuàng)建查詢多打點計時懶加載緩存權限泄露默認上下文權限過高檢查默認值改為最小權限默認測試難寫上下文依賴全局狀態(tài)檢查是否用了全局變量改為顯式傳遞這張表是我從多次踩坑里總結(jié)出來的基本上覆蓋了context-mode落地時80%的問題。每次遇到新問題我會先對照這張表排查通常能快速定位。5.4 幾個容易忽略的細節(jié)第一個細節(jié)是上下文的日志輸出。上下文里可能包含敏感信息比如用戶ID、租戶ID。直接打到日志里可能違反隱私要求。我的做法是日志里只輸出request_id和少量非敏感字段需要詳細信息時通過request_id去查專門的審計日志。第二個細節(jié)是上下文的版本兼容。當上下文結(jié)構(gòu)發(fā)生變化時比如新增一個字段舊版本的服務可能不認識新字段。如果上下游服務版本不一致可能會出現(xiàn)字段缺失。解決辦法是新增字段時給默認值刪除字段時先標記廢棄等所有服務都升級后再刪。第三個細節(jié)是上下文的清理。在長駐進程里比如Web服務器contextvars是線程/協(xié)程隔離的請求結(jié)束后上下文會自然失效。但如果你手動設置了全局的上下文記得在請求結(jié)束時清理避免影響下一個請求。最后分享一個小技巧我會在開發(fā)環(huán)境里加一個調(diào)試端點輸入request_id就能看到那次請求的完整上下文快照。這個端點在上線時關掉但在排查問題時特別有用。比翻日志快多了。6. 上下文模式的擴展玩法6.1 在大模型會話管理中的應用context-mode這套思路在大模型應用里特別有用。一次多輪對話就是一個上下文里面包含用戶身份、歷史消息、當前意圖、可用工具列表。每次生成回復時根據(jù)上下文決定用哪個模型、帶多少歷史、調(diào)用哪些工具。我做過一個客服機器人上下文里有個escalation_level字段表示當前對話的升級程度。第一輪是普通問答如果用戶表達不滿升級到二級上下文里會加入“可以承諾補償”的權限。如果用戶要求轉(zhuǎn)人工升級到三級上下文里會加入人工客服的排隊信息。整個流程用上下文驅(qū)動比寫一堆if-else清晰多了。6.2 在灰度發(fā)布中的應用灰度發(fā)布本質(zhì)上就是根據(jù)上下文決定走新邏輯還是舊邏輯。上下文里放用戶ID的哈希值、客戶端版本、地區(qū)等字段然后一個決策函數(shù)判斷“這個用戶是否在灰度范圍內(nèi)”。新邏輯和舊邏輯并存通過上下文切換。等灰度驗證通過再把舊邏輯刪掉。這種做法的好處是灰度規(guī)則可以動態(tài)調(diào)整不需要重新部署。比如今天灰度10%的用戶明天發(fā)現(xiàn)沒問題改成50%只需要改配置不用改代碼。6.3 在插件系統(tǒng)中的應用如果你在做一個插件系統(tǒng)每個插件可能需要不同的上下文。比如一個數(shù)據(jù)導出插件需要知道當前租戶的存儲配額一個通知插件需要知道用戶的聯(lián)系方式。你可以定義一個基礎上下文然后每個插件聲明自己需要哪些字段。系統(tǒng)在調(diào)用插件前根據(jù)插件聲明組裝上下文。這樣插件之間互不干擾新增插件也不需要改核心邏輯。這種模式的關鍵是上下文契約插件聲明需要什么系統(tǒng)保證提供什么。契約清晰了插件開發(fā)就變成了填坑游戲簡單可控。我個人在實際操作中的體會是context-mode最大的價值不是技術上的而是溝通上的。當團隊里所有人都用“上下文”這個詞來討論問題時很多模糊的需求會變得清晰。產(chǎn)品經(jīng)理說“移動端用戶應該看到不同的界面”工程師會追問“這個不同是基于平臺字段還是基于客戶端版本字段”。這種追問能提前暴露很多理解偏差減少返工。所以如果你打算引入context-mode不妨先從統(tǒng)一術語開始讓團隊里所有人都理解“上下文”指的是什么然后再動代碼。