1. 从“context-mode”说起：一个被低估的工程概念
第一次看到“context-mode”这个词，很多人会下意识地把它归到某个具体框架的配置项里，比如某个前端库的渲染模式、某个数据库的连接上下文、又或者是某个AI工具里的对话上下文开关。但如果你真的在工程一线待过几年，就会发现“context-mode”其实是一个横跨多个技术领域的通用设计思路——它描述的是系统在不同上下文环境下，如何切换自身的行为模式、资源分配策略和数据处理方式。
我最早接触这个概念是在做后端服务治理的时候。当时我们有一套API网关，需要同时服务Web端、移动端和第三方合作方。Web端希望拿到完整的JSON数据，移动端希望字段精简、流量小，第三方则要求特定的签名和字段映射。如果每个端都写一套独立逻辑，维护成本会爆炸。后来我们引入了一个“context-mode”的设计：网关根据请求头里的上下文标识（来源、版本、设备类型），动态切换序列化策略、字段过滤规则和缓存策略。同一套核心业务逻辑，对外呈现出完全不同的行为。这就是context-mode最朴素的价值——用一套内核，适配多种上下文。
把这个思路放大来看，你会发现它无处不在。前端框架里的“渲染模式”（CSR、SSR、SSG、ISR）本质上就是context-mode：根据页面类型、用户登录状态、数据更新频率，选择不同的渲染上下文。数据库里的“连接模式”（长连接、短连接、连接池）也是context-mode：根据事务类型、并发量、超时要求，切换连接管理策略。甚至你手机上的“省电模式”“性能模式”“均衡模式”，都是操作系统层面的context-mode切换。
所以这篇博文，我想把“context-mode”当作一个工程方法论来拆解，而不是某个具体产品的功能说明。我会从设计思路、核心实现、实操落地、问题排查四个维度，把我在实际项目中积累的经验和踩过的坑，尽可能完整地分享出来。无论你是做后端、前端、移动端还是数据工程，只要你的系统需要“在不同场景下表现出不同行为”，这套思路都能直接参考。
注意：context-mode不是某个标准术语，不同团队、不同框架里叫法可能不同。有的叫“策略模式+上下文”，有的叫“环境感知路由”，有的叫“多模态适配层”。名字不重要，重要的是背后的设计逻辑。
2. 核心设计思路：为什么需要上下文模式
2.1 从“硬编码分支”到“上下文驱动”的演进
大部分系统在早期阶段，处理不同场景的方式非常直接：写if-else。比如一个内容接口，如果是移动端请求，就少返回几个字段；如果是Web端，就返回完整数据。代码大概长这样：
def get_content(request): if request.device == "mobile": return {"title": ..., "summary": ...} elif request.device == "web": return {"title": ..., "summary": ..., "body": ..., "related": ...} elif request.device == "api": return {"code": 0, "data": {...}}这种写法在场景少于3个、逻辑简单的时候没问题。但一旦场景增加到5个、10个，每个场景的差异点从字段过滤扩展到缓存策略、鉴权方式、限流阈值、错误码格式，if-else就会变成一座无法维护的“屎山”。更致命的是，每次新增一个场景，你都要改动核心业务代码，回归测试范围急剧扩大。
context-mode的核心思路就是把“上下文识别”和“上下文处理”解耦。系统不再在业务逻辑里判断“当前是什么场景”，而是由一层专门的上下文解析器来识别场景，然后路由到对应的处理策略。业务代码只关心“在这个上下文下，我应该怎么做”，不关心“为什么是这个上下文”。
2.2 上下文模式的三层结构
我在实际项目中总结出来的context-mode实现，通常包含三个层次：
第一层：上下文采集与识别。这一层负责从请求、环境、配置、用户状态等来源收集信息，并判断当前属于哪种上下文。采集的信息可能包括：请求来源（Web/移动/第三方）、用户角色（游客/普通用户/管理员）、设备能力（网络类型、屏幕尺寸、算力等级）、业务场景（浏览/编辑/导出）、系统状态（负载高低、降级开关）等。识别方式可以是规则匹配、优先级队列、甚至简单的机器学习分类。
第二层：上下文策略映射。这一层维护一个“上下文-策略”的映射表。每个上下文对应一组策略配置，包括：数据处理策略（字段过滤、序列化格式）、资源分配策略（线程池、连接池、缓存TTL）、行为策略（重试次数、超时时间、降级方案）。映射表可以是静态配置，也可以是动态下发的。
第三层：策略执行与反馈。这一层负责实际执行策略，并收集执行结果。如果某个上下文下的策略执行失败率升高，可以触发告警或自动切换降级策略。反馈数据还可以用来优化上下文识别规则和策略配置。
这三层结构的好处是：新增上下文时，只需要在采集层增加识别规则，在映射层增加策略配置，不需要改动执行层的核心逻辑。执行层始终保持稳定，回归测试范围可控。
2.3 什么场景适合引入context-mode
不是所有系统都需要context-mode。如果你的系统只有一种调用方、一种数据格式、一种资源策略，引入context-mode只会增加复杂度。但如果你遇到以下情况，就值得考虑：
- 多端适配：同一套后端服务需要同时服务Web、移动端、小程序、第三方API，各端对数据格式、字段、性能的要求差异明显。
- 多租户SaaS：不同租户对功能开关、数据隔离、配额限制、品牌定制有不同要求。
- 灰度发布与AB测试：需要根据用户分群、流量比例、地域等上下文，路由到不同版本的服务。
- 降级与熔断：系统负载高时，需要自动切换到“精简模式”，关闭非核心功能，保证核心链路可用。
- 国际化与本地化：不同地区对时间格式、货币单位、内容合规要求不同，需要上下文感知的格式化策略。
我个人的经验是：当你的if-else分支超过5个，且每个分支的差异点超过3个维度时，就是引入context-mode的最佳时机。再晚，重构成本会指数级上升。
3. 核心实现细节：从配置到代码的完整落地
3.1 上下文标识的设计与传递
context-mode落地的第一步，是设计一套清晰、可扩展的上下文标识体系。这套标识需要在整个调用链路中传递，从入口网关一直透传到最底层的业务逻辑。
我通常采用“主上下文+子上下文”的二级结构。主上下文标识大的场景类别，比如web、mobile、openapi、internal。子上下文标识更细粒度的差异，比如mobile:ios、mobile:android、mobile:low_end。这样设计的好处是，策略配置可以按主上下文设置默认值，再按子上下文做覆盖。
标识的传递方式取决于你的技术栈。在HTTP服务中，通常放在请求头里，比如：
X-Context-Main: mobile X-Context-Sub: ios X-Context-Version: 2.3.1 X-Context-Capability: low在微服务内部调用时，可以放在RPC的attachment里，或者通过链路追踪的baggage传递。关键原则是：上下文标识必须贯穿整个调用链，不能在中途丢失。我见过太多系统，网关识别了上下文，但到了下游服务就丢了，导致下游只能重新识别或者干脆不识别。
实操心得：上下文标识不要设计得太复杂。我见过一个团队把用户ID、设备指纹、网络延迟、电池电量全塞进上下文标识里，结果每次请求要传几十个字段，解析成本比业务逻辑还高。建议主上下文不超过3个字段，子上下文不超过5个字段，其他信息通过上下文ID去缓存或配置中心查询。
3.2 策略配置的组织方式
策略配置是context-mode的核心。我推荐使用“默认配置+上下文覆盖”的方式，而不是为每个上下文写一份完整配置。这样配置量小，且默认配置变更时，所有上下文自动继承。
以字段过滤策略为例，配置可以这样组织：
default: fields: - id - title - summary - body - related - author cache_ttl: 300 timeout_ms: 2000 contexts: mobile: fields: - id - title - summary cache_ttl: 600 timeout_ms: 1500 mobile:low_end: fields: - id - title cache_ttl: 900 timeout_ms: 1000 openapi: fields: - id - title - body cache_ttl: 60 timeout_ms: 3000这种配置方式的好处是，mobile上下文只需要声明与默认配置的差异，不需要重复写related、author等字段。当默认配置新增字段时，所有上下文自动获得该字段，除非显式排除。
策略配置的存储位置也很关键。静态配置可以放在代码仓库里，随服务发布。动态配置建议放在配置中心，支持热更新。我通常会把“字段过滤”“缓存TTL”这类影响面小的策略放在动态配置，把“鉴权方式”“限流阈值”这类安全相关的策略放在静态配置，变更走发布流程。
3.3 策略执行引擎的实现
策略执行引擎是context-mode的“大脑”。它需要根据上下文标识，从配置中加载对应的策略，然后按顺序执行。我通常把执行过程分为三个阶段：
前置阶段：在业务逻辑执行前，完成上下文解析、策略加载、参数校验、限流检查。这个阶段的目标是“快速失败”，如果上下文不合法或策略不允许，直接返回错误，不进入业务逻辑。
执行阶段：业务逻辑执行时，通过一个“上下文对象”来获取当前策略。比如在Python中，可以这样使用：
class Context: def __init__(self, main, sub, config): self.main = main self.sub = sub self.config = config def get_fields(self): return self.config.get("fields", []) def get_cache_ttl(self): return self.config.get("cache_ttl", 300) def get_timeout(self): return self.config.get("timeout_ms", 2000) def get_content(ctx: Context, content_id): fields = ctx.get_fields() ttl = ctx.get_cache_ttl() timeout = ctx.get_timeout() # 后续业务逻辑使用这些策略参数 ...后置阶段：业务逻辑执行后，根据策略决定是否缓存、如何序列化、是否记录审计日志。这个阶段还可以收集执行指标，用于监控和优化。
注意事项：策略执行引擎本身必须非常轻量。我见过一个实现，每次请求都要从配置中心拉取全量配置，然后做复杂的规则匹配，导致P99延迟增加了50ms。后来改成“本地缓存+版本号比对”，只有配置版本变化时才重新拉取，延迟降到了1ms以内。
3.4 上下文识别规则的优先级设计
当多个上下文规则同时匹配时，需要有明确的优先级。我通常采用“精确优先、子上下文优先、后定义优先”的原则。
举个例子：一个请求同时满足mobile（主上下文）和mobile:ios（子上下文）的匹配条件。那么应该优先使用mobile:ios的策略，因为它更精确。如果还有一条mobile:ios:version_2_3的规则，那就更优先。
优先级设计不好，会导致策略覆盖混乱。我建议在配置中显式声明优先级数值，而不是依赖定义顺序。比如：
contexts: mobile: priority: 10 mobile:ios: priority: 20 mobile:ios:version_2_3: priority: 30这样即使配置项的顺序被打乱，优先级也不会变。排查问题时，也可以直接打印当前生效的上下文和优先级，一目了然。
4. 实操过程：从零搭建一个上下文模式框架
4.1 环境准备与技术选型
在动手之前，先明确技术选型。context-mode本身不依赖特定语言或框架，但不同技术栈的实现方式差异很大。我以Python + FastAPI为例，因为这套组合在中小型项目中落地最快，且代码可读性好。
需要准备的环境：
- Python 3.9+
- FastAPI（Web框架）
- Pydantic（配置校验）
- Redis（缓存和配置存储）
- PyYAML（配置文件解析）
如果你用的是Java，可以用Spring Boot + AOP + Apollo配置中心。如果是Go，可以用Gin + Viper + etcd。核心思路一样，只是实现细节不同。
4.2 上下文解析器的实现
先实现上下文解析器。它的职责是从请求中提取上下文标识，并做合法性校验。
from fastapi import Request, HTTPException from pydantic import BaseModel from typing import Optional class ContextInfo(BaseModel): main: str sub: Optional[str] = None version: Optional[str] = None capability: Optional[str] = None VALID_MAIN_CONTEXTS = {"web", "mobile", "openapi", "internal"} VALID_SUB_CONTEXTS = { "mobile": {"ios", "android", "low_end"}, "web": {"desktop", "tablet"}, } def parse_context(request: Request) -> ContextInfo: main = request.headers.get("X-Context-Main", "web") sub = request.headers.get("X-Context-Sub") version = request.headers.get("X-Context-Version") capability = request.headers.get("X-Context-Capability") if main not in VALID_MAIN_CONTEXTS: raise HTTPException(status_code=400, detail=f"Invalid context main: {main}") if sub and main in VALID_SUB_CONTEXTS: if sub not in VALID_SUB_CONTEXTS[main]: raise HTTPException(status_code=400, detail=f"Invalid sub context: {sub}") return ContextInfo(main=main, sub=sub, version=version, capability=capability)这段代码的关键点是：校验规则要可配置，不要硬编码在代码里。我通常把VALID_MAIN_CONTEXTS和VALID_SUB_CONTEXTS放在配置文件或配置中心，这样新增上下文时不需要改代码。
4.3 策略加载与缓存机制
策略加载的性能直接影响整个context-mode的收益。如果每次请求都要读配置文件或查数据库，那还不如不用。我采用“本地缓存+Redis版本号”的方案。
import yaml import redis from threading import Lock class StrategyLoader: def __init__(self, config_path, redis_client): self.config_path = config_path self.redis = redis_client self.local_cache = {} self.local_version = None self.lock = Lock() def _load_from_file(self): with open(self.config_path, "r") as f: return yaml.safe_load(f) def get_strategy(self, ctx: ContextInfo): remote_version = self.redis.get("context_mode:version") remote_version = remote_version.decode() if remote_version else "0" if self.local_version != remote_version: with self.lock: if self.local_version != remote_version: self.local_cache = self._load_from_file() self.local_version = remote_version return self._resolve(ctx) def _resolve(self, ctx: ContextInfo): config = self.local_cache default = config.get("default", {}) contexts = config.get("contexts", {}) # 按优先级从高到低匹配 candidates = [] if ctx.main in contexts: candidates.append((contexts[ctx.main].get("priority", 10), contexts[ctx.main])) if ctx.sub: key = f"{ctx.main}:{ctx.sub}" if key in contexts: candidates.append((contexts[key].get("priority", 20), contexts[key])) if ctx.version: key = f"{ctx.main}:{ctx.sub}:{ctx.version}" if ctx.sub else f"{ctx.main}:{ctx.version}" if key in contexts: candidates.append((contexts[key].get("priority", 30), contexts[key])) candidates.sort(key=lambda x: x[0], reverse=True) merged = dict(default) for _, ctx_config in candidates: merged.update(ctx_config) return merged这个实现的核心是：本地缓存避免每次请求都读文件，Redis版本号保证配置变更能及时感知。版本号更新由配置发布流程触发，比如运维在配置中心修改配置后，自动递增Redis里的版本号。
实操心得：本地缓存的更新不要用定时轮询，那样会有延迟。用版本号比对的方式，每次请求只多一次Redis GET操作，成本极低，但能保证配置变更在秒级生效。如果Redis不可用，可以降级为“使用本地缓存+定期刷新”，保证系统可用性。
4.4 在业务逻辑中注入上下文
策略加载好后，需要注入到业务逻辑中。我推荐用依赖注入的方式，而不是全局变量。FastAPI的Depends机制很适合：
from fastapi import Depends async def get_context(request: Request) -> ContextInfo: return parse_context(request) async def get_strategy(ctx: ContextInfo = Depends(get_context)): loader = StrategyLoader("context_config.yaml", redis_client) return loader.get_strategy(ctx) @app.get("/content/{content_id}") async def get_content( content_id: str, ctx: ContextInfo = Depends(get_context), strategy: dict = Depends(get_strategy), ): fields = strategy.get("fields", []) ttl = strategy.get("cache_ttl", 300) timeout = strategy.get("timeout_ms", 2000) # 模拟业务逻辑 content = fetch_content_from_db(content_id, timeout) filtered = {k: v for k, v in content.items() if k in fields} # 根据策略决定是否缓存 if ttl > 0: cache_key = f"content:{content_id}:{ctx.main}:{ctx.sub}" redis_client.setex(cache_key, ttl, json.dumps(filtered)) return filtered这种写法的好处是：业务逻辑只依赖抽象的strategy字典，不关心上下文如何解析、策略如何加载。测试时，可以轻松mock一个strategy，不需要构造完整的请求头。
4.5 监控与反馈闭环
context-mode上线后，必须配套监控。否则你无法知道哪个上下文下的策略执行异常、哪个上下文的流量在增长、哪个策略的缓存命中率低。
我通常监控以下指标：
| 指标名称 | 含义 | 告警阈值 |
|---|---|---|
| context_request_total | 各上下文请求量 | 单上下文突增50% |
| context_error_rate | 各上下文错误率 | 超过1% |
| context_latency_p99 | 各上下文P99延迟 | 超过策略timeout的80% |
| strategy_cache_hit | 策略缓存命中率 | 低于95% |
| context_fallback_total | 降级触发次数 | 5分钟内超过10次 |
这些指标按上下文维度打标签，在Grafana上分上下文展示。一旦某个上下文的错误率或延迟异常，可以快速定位是该上下文的策略配置问题，还是该上下文对应的下游服务问题。
反馈闭环还包括：定期review各上下文的策略配置，清理长期无流量的上下文，合并差异过小的上下文。我见过一个系统，上下文数量从最初的5个膨胀到30多个，很多上下文只有零星流量，维护成本极高。后来做了一次清理，合并到8个，配置复杂度下降了70%。
5. 常见问题与排查技巧实录
5.1 上下文丢失导致策略不生效
这是最常见的问题。表现是：明明配置了mobile上下文的策略，但移动端请求还是走了默认策略。排查思路：
- 检查请求头是否携带上下文标识。用curl或Postman直接发请求，看请求头里有没有
X-Context-Main。 - 检查网关是否透传。很多网关默认只透传部分请求头，需要在网关配置里把
X-Context-*加入白名单。 - 检查服务间调用是否传递。如果是微服务架构，A服务调用B服务时，需要手动把上下文标识放到RPC的attachment里。我见过一个团队，网关到A服务传递了，A到B没传，导致B服务一直用默认策略。
- 检查上下文解析器的默认值。如果请求头缺失，解析器可能给了默认值
web，导致移动端请求被当成Web端处理。建议在解析器里对缺失关键标识的请求打日志，方便排查。
避坑技巧：在开发环境强制要求所有请求必须携带上下文标识，缺失直接返回400。这样可以在开发阶段就暴露问题，而不是等到生产环境才发现策略不生效。
5.2 策略冲突与覆盖顺序混乱
当多个上下文规则同时匹配时，如果优先级设计不清晰，会出现“策略覆盖不符合预期”的问题。比如mobile:ios的策略被mobile的策略覆盖了，导致iOS端拿到了Android端的字段配置。
排查方法：在策略加载后，打印最终生效的上下文和合并后的策略配置。我通常会在日志里加一行：
logger.info(f"context={ctx.main}:{ctx.sub}, priority={matched_priority}, strategy_keys={list(merged.keys())}")这样一眼就能看出哪个上下文生效了、优先级是多少、最终策略包含哪些字段。如果发现优先级不对，检查配置里的priority数值，确保子上下文优先级高于主上下文。
5.3 配置热更新不生效
配置中心修改了策略，但服务没有感知到。原因通常是本地缓存没有及时刷新。排查步骤：
- 检查Redis里的版本号是否已经更新。如果没更新，说明配置发布流程没有触发版本号递增。
- 检查服务是否成功连接到Redis。如果Redis连接失败，本地缓存会一直用旧版本。
- 检查本地缓存的更新逻辑是否有锁竞争。高并发下，如果多个线程同时发现版本号变化，可能会重复加载配置，但最终结果应该一致。如果出现不一致，检查锁的粒度是否合适。
实操心得：配置热更新不要追求“实时”，秒级生效已经足够。我见过一个团队为了追求毫秒级生效，每次请求都去配置中心拉取，结果配置中心成了瓶颈。后来改成“版本号比对+本地缓存”，配置变更在1-2秒内生效，完全满足业务需求。
5.4 上下文数量膨胀导致维护困难
这是context-mode落地后最容易出现的问题。每个业务方都希望有自己的上下文，结果上下文数量从5个涨到50个，配置管理变成噩梦。
我的经验是：建立上下文准入机制。新增上下文必须满足以下条件之一：
- 该上下文的策略差异点超过3个维度；
- 该上下文的流量占比超过5%；
- 该上下文有明确的合规或安全要求。
不满足条件的，建议通过“子上下文”或“策略参数”的方式复用现有上下文。比如，如果只是某个渠道需要多返回一个字段，不需要新建上下文，可以在现有上下文里加一个channel参数，策略配置里根据channel做条件判断。
定期清理也是必要的。我通常每季度做一次上下文审计，把连续30天流量为0的上下文标记为“待废弃”，再观察30天后删除。这样能保持上下文数量在可控范围内。
5.5 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| 策略不生效 | 上下文标识丢失 | 检查请求头和网关透传配置 | 补全标识传递链路 |
| 策略覆盖错误 | 优先级配置错误 | 打印生效上下文和优先级 | 调整priority数值 |
| 配置不更新 | 版本号未变或Redis不可用 | 检查Redis版本号和连接 | 修复发布流程或Redis |
| 延迟增加 | 策略加载过重 | 检查策略加载耗时 | 加本地缓存，减少远程调用 |
| 上下文膨胀 | 缺乏准入机制 | 统计各上下文流量 | 建立准入和清理机制 |
| 降级不触发 | 降级条件配置错误 | 检查降级阈值和监控指标 | 调整阈值，补充监控 |
6. 进阶玩法：上下文模式与AI能力的结合
6.1 用上下文模式管理AI对话状态
如果你在做AI应用，context-mode的思路同样适用。AI对话里的“上下文窗口”本质上就是一种context-mode：根据对话轮次、用户意图、历史消息长度，动态决定保留多少历史消息、使用什么温度参数、调用哪个模型。
我试过用类似的结构来管理AI对话：
class AIContext: def __init__(self, user_tier, intent, history_len): self.user_tier = user_tier self.intent = intent self.history_len = history_len def get_model(self): if self.intent == "code": return "code-model" if self.user_tier == "premium": return "large-model" return "small-model" def get_max_tokens(self): if self.user_tier == "premium": return 4096 return 1024 def get_history_window(self): if self.history_len > 20: return 10 return self.history_len这样，同一个AI服务可以根据用户等级、意图类型、对话长度，动态切换模型、token上限和历史窗口。既保证了高端用户的体验，又控制了低端用户的成本。
6.2 上下文模式在数据管道中的应用
数据工程里，context-mode可以用来管理不同数据源的同步策略。比如，实时数据源用流式处理，批量数据源用定时任务，API数据源用轮询。每种数据源对应一个上下文，策略配置里定义同步频率、错误重试次数、数据格式转换规则。
我做过一个数据同步平台，支持MySQL、PostgreSQL、MongoDB、REST API四种数据源。最初每种数据源写一套同步逻辑，代码重复率很高。后来引入context-mode，把“连接管理”“增量识别”“错误重试”“格式转换”抽象成策略，不同数据源只需要实现自己的策略插件。新增一种数据源，从原来的3天工作量降到半天。
6.3 上下文模式的边界与取舍
context-mode不是银弹。它解决的是“多场景适配”的问题，但会引入额外的抽象层和配置复杂度。如果你的系统只有一种场景，或者场景差异极小，引入context-mode反而会增加维护成本。
我的判断标准是：当“场景差异带来的代码重复”超过“抽象层带来的复杂度”时，才引入context-mode。具体来说，如果你发现同一个功能在3个以上地方有相似但不完全相同的实现，且每次修改都要改多处，那就是引入context-mode的信号。
另外，context-mode的配置管理需要配套的流程和工具。如果没有配置中心、没有版本管理、没有监控告警，context-mode很容易变成“配置地狱”。所以，在引入context-mode之前，先确保你的基础设施能支撑配置的动态管理和可观测性。
7. 我个人在实际操作中的体会
做了这么多年的多场景适配，我最大的体会是：context-mode的核心不是技术，而是边界划分。哪些差异应该放在上下文里，哪些差异应该放在业务逻辑里，这个边界划错了，后面怎么实现都别扭。
我的经验是：与“谁在调用”相关的差异，放在上下文里；与“业务规则”相关的差异，放在业务逻辑里。比如，移动端要少返回字段，这是“谁在调用”的差异，放上下文。而“VIP用户可以看到隐藏内容”，这是业务规则，放业务逻辑。边界清晰了，上下文配置就不会膨胀，业务逻辑也不会被上下文污染。
另一个体会是：上下文模式需要配套的文档和工具。我见过太多团队，context-mode实现得很漂亮，但没有文档，新人来了不知道有哪些上下文、每个上下文什么含义、新增上下文怎么操作。结果就是老人一走，这套机制就荒废了。所以，我现在的习惯是：每新增一个上下文，必须同步更新三样东西——上下文清单文档、策略配置模板、监控看板。这三样齐了，才算真正落地。
最后分享一个小技巧：在日志里始终打印当前生效的上下文标识。这个习惯帮我省了无数排查时间。每次看到异常日志，第一眼就能知道是哪个上下文出的问题，然后直接去查该上下文的策略配置，效率提升非常明显。
