1. 为什么“Gemini CLI 进阶玩法”不是命令行技巧堆砌而是一场工作流重构你有没有过这种体验在终端里敲下gemini命令等它返回一段文字然后复制粘贴进编辑器、再手动保存为文件、再打开 Git 客户端提交——整个过程像在用乐高积木搭一座桥每块砖都得亲手对齐、按压、确认卡扣到位。这不是效率这是体力劳动。我第一次把 Gemini CLI 当成“高级聊天框”用时也这么干。直到某天凌晨三点我需要为一个紧急上线的 API 补充 17 个端点的 OpenAPI 描述同时生成对应的 Postman 集合和单元测试骨架。我本能地想打开浏览器查文档、开 VS Code 写 YAML、再切到终端跑测试……手指悬在键盘上停了两秒突然意识到Gemini CLI 本身就是一个可编程的、带上下文感知能力的自动化引擎而我一直在把它当计算器用。“进阶玩法”的核心从来不是记住更多--flag参数而是理解它如何把“人脑指令”翻译成“机器可执行的原子动作流”。关键词Model Context ProtocolMCP就是这台引擎的燃料注入口——它让 Gemini CLI 不再是单向输出文本的模型接口而是一个能主动调用外部工具、读取本地文件、连接数据库、甚至控制 Docker 容器的“数字协作者”。这解释了为什么热搜词里反复出现chrome://extensions/和gemini出了点问题大量用户卡在“怎么让 Gemini 看到我的代码”“为什么它总说找不到项目结构”“我装了插件但 CLI 里没反应”——这些根本不是故障而是工作流断层。CLI 和浏览器插件本质是同一套 MCP 协议的两种载体一个在终端里跑一个在浏览器里跑它们共享同一个配置中心settings.json、同一套工具注册机制、同一种资源引用语法server://path。当你在 Chrome 里看到 Gemini 消失大概率是因为你的 MCP 服务器配置在 CLI 里被禁用了当你在终端里执行/mcp list显示DISCONNECTED浏览器插件自然也同步失联。所以这篇“详细版”不讲基础安装不列命令速查表。我要带你拆开 Gemini CLI 的外壳看清它的 MCP 协议栈如何运作、为什么trust: true是把双刃剑、如何用includeTools精准狙击一个危险函数、以及最关键的——如何把日常重复操作比如生成 PR 描述、检查依赖漏洞、导出数据库 Schema变成一句/pr-describe --branchfeat/login就能触发的全自动流水线。这不是 CLI 的“高级功能”这是重新定义你和开发工具之间的契约关系。2. MCP 协议栈深度解剖从协议规范到内存中的实时映射Model Context ProtocolMCP常被简化为“让大模型调用工具的协议”这就像说 TCP/IP 是“让电脑发消息的协议”一样正确但苍白。真正的力量藏在它的分层设计里发现层Discovery Layer决定“有什么”执行层Execution Layer决定“怎么用”而传输层Transport决定“怎么连”。这三层不是静态配置而是在 CLI 启动瞬间动态构建的一张实时内存图谱。2.1 发现层discoverMcpTools()如何成为你的“数字侦察兵”当你执行gemini命令启动 CLI第一件事不是加载模型而是运行packages/core/src/tools/mcp-client.ts中的discoverMcpTools()函数。这个函数不是简单地 ping 一下服务器而是一套精密的五步侦察流程服务器迭代与连接它会遍历settings.json中mcpServers对象下的每一个键如pythonTools为每个服务器创建一个独立的连接状态机。注意这里的command、url、httpUrl三者互斥CLI 会根据你配置的字段自动选择传输类型——command触发 Stdio子进程url触发 SSE服务端事件httpUrl触发 Streamable HTTP流式 HTTP。关键细节在于超时控制默认 10 分钟600,000ms的 timeout 并非固定值而是针对每个服务器单独计时。如果你有一个需要 3 分钟预热的 Python 工具服务器必须显式设置timeout: 180000否则它永远卡在CONNECTING状态。工具发现连接成功后CLI 会向服务器发起标准 MCP 协议的tools/list请求。这里有个极易踩坑的点很多开发者误以为只要返回 JSON 数组就行但 MCP 要求严格遵循 OpenAPI 3.0 的 Function Schema 格式。例如一个计算文件哈希的工具其 schema 必须包含{ name: file_hash, description: Calculate SHA256 hash of a file, parameters: { type: object, properties: { filepath: { type: string, description: Path to the file } }, required: [filepath] } }如果你漏掉required字段或把type写成string而非objectCLI 会在日志里静默丢弃该工具只显示No tools discovered而不会报错。我曾为此调试了 4 小时最后发现是zod库生成的 schema 缺少required—— 因为z.object({})默认不强制任何字段。工具命名与命名空间发现工具后CLI 会强制为其添加前缀mcp_{serverName}_{toolName}。比如pythonTools服务器下的file_analyzer工具最终注册名为mcp_pythonTools_file_analyzer。这个前缀规则有致命陷阱服务器名中绝对不能含下划线_。文档里那句 “Caution: Do not use underscores in your MCP server names” 不是建议是铁律。因为策略引擎Policy Engine解析 FQN 时会以第一个_为界分割mcp_后的部分。若你配置my_server: {...}工具名变成mcp_my_server_file_analyzer策略引擎会错误地将my识别为服务器名server_file_analyzer当作工具名导致所有安全策略失效。实测中excludeTools: [file_analyzer]对my_server完全无效必须写成excludeTools: [server_file_analyzer]——这违背直觉却符合底层解析逻辑。Schema 处理CLI 会对工具参数 schema 进行三重净化移除$schema字段避免与 Vertex AI 冲突、剥离additionalProperties防止模型传入非法参数、递归清理嵌套 schema 中的默认值。这意味着如果你的工具 schema 里写了default: utf-8CLI 会直接删掉它模型调用时若不显式传参工具收到的将是undefined而非utf-8。解决方案不是硬编码默认值而是在工具实现层做兜底Python 示例中def file_hash(filepath: str, encoding: str utf-8):比在 schema 里写 default 更可靠。连接管理发现完成后CLI 会关闭那些“注册了工具但工具列表为空”的服务器连接但会维持所有成功注册工具的连接。这解释了为什么gemini mcp list里有些服务器显示CONNECTED却没有工具——它们可能因 schema 校验失败被过滤但连接未被释放。此时需用gemini mcp remove彻底清理再重新添加。提示要观察完整的发现过程在启动 CLI 时加--debug参数。你会看到类似DEBUG mcp-client: Server pythonTools connection state changed to CONNECTING的日志。比--debug更有效的是直接看 stderrMCP 服务器进程的console.error输出会被 CLI 捕获并原样打印这是定位服务器内部错误如数据库连接失败的唯一途径。2.2 执行层DiscoveredMCPTool如何成为你的“信任代理”当模型生成{name: mcp_pythonTools_file_analyzer, args: {filepath: ./src/main.py}}时真正执行的不是裸调用而是mcp-tool.ts中的DiscoveredMCPTool实例。它像一个戴着三重面具的代理人第一层面具信任决策Trust Decisionif (this.trust) { return false; }这行代码决定了是否弹出确认框。trust: true在配置中意味着“跳过所有人工确认”但它不等于“无条件执行”。CLI 仍会校验参数类型、执行超时、处理网络错误。真正的风险在于一旦开启 trust所有工具调用都绕过用户二次确认包括你后来通过gemini mcp add添加的、未经过充分测试的新工具。我的实践是仅对localhost上的、源码完全可控的 Python 工具服务器启用trust: true对任何 HTTP/SSE 远程服务器即使内网也保持trust: false并用gemini mcp enable --session临时开启。第二层面具参数熔断Parameter Circuit Breaker在执行前DiscoveredMCPTool会用工具的原始 schema未经 CLI 净化的版本验证args。如果模型传入{filepath: null}而 schema 要求filepath是string验证失败工具直接拒绝执行返回清晰的错误“Argument filepath must be a string”。这比让工具自己崩溃更友好因为错误发生在模型上下文内CLI 可以提示模型“请提供有效的文件路径”。第三层面具响应翻译Response Translator工具返回的原始 JSON如{hash: a1b2c3...}会被DiscoveredMCPTool拆解为两部分llmContent供模型继续推理的纯文本和returnDisplay给用户看的格式化输出。returnDisplay默认是 Markdown 代码块但你可以通过content字段返回富媒体。例如一个截图工具返回{ content: [ {type: text, text: 已截取当前屏幕以下是缩略图}, {type: image, data: base64..., mimeType: image/png} ] }CLI 会把文本拼成一段话把图片渲染为内联图像并将完整数据注入模型上下文。这就是“多模态上下文”的实现原理——不是模型天生能看图而是 CLI 把二进制数据转译为模型能消化的 token 流。2.3 传输层Stdio、SSE、HTTP 三种通道的本质差异传输类型启动方式连接特性适用场景我的选型经验Stdiospawn(command, args)进程级隔离启动快无网络依赖本地脚本、Python/Node.js 工具服务器、需要访问本地文件系统90% 的自建工具用它。cwd字段必须设为项目根目录否则./src/file.py引用会失败SSEnew EventSource(url)长连接服务端主动推送低延迟实时日志监控、CI/CD 状态推送、需要服务端事件驱动的场景配置 OAuth 时首选因EventSource自动处理重连和鉴权头Streamable HTTPfetch(url, { method: POST, body: stream })兼容性最好支持任意 HTTP 方法和头与现有 REST API 集成、需要复杂认证如 JWT Bearer当工具已部署为云函数时用它最省事headers可直接传Authorization一个反直觉的事实Stdio 传输的性能未必最高。当你的 Python 工具服务器每次启动都要加载 200MB 的 ML 模型时spawn的冷启动延迟远高于 SSE 的长连接复用。这时应改用 SSE并在服务器端做模型单例缓存。我在一个 NLP 文本分类工具中将启动时间从 8 秒降至 0.3 秒就靠这个切换。3. 从零构建一个生产级 MCP 工具服务器以“PR 描述生成器”为例理论终需落地。我们来构建一个真实解决痛点的工具根据 Git 提交记录和代码变更自动生成符合团队规范的 Pull Request 描述。这不是玩具 demo而是我每天在用的生产力工具。3.1 为什么不用现成的 GitHub MCP 服务器官方github/github-mcp-server功能强大但它面向通用场景无法满足我们的定制需求要求 PR 描述必须包含## ✨ 新增功能、## 修复问题、## 文档更新三个固定章节需要自动提取 Jira Issue ID如PROJ-123并链接到公司内部 Jira必须扫描package.json的dependencies变更生成## 依赖更新列表对于删除的文件要标注⚠️ 已移除src/legacy/utils.js。这些规则无法通过配置开关实现必须写业务逻辑。所以我们自己造轮子。3.2 工具服务器架构Python FastAPI MCP SDK选择 Python 因为生态丰富git命令行封装GitPython、Jira APIjira、前端模板Jinja2一应俱全开发效率高快速迭代业务逻辑无需编译与 CLI Stdio 传输天然契合。项目结构pr-describer/ ├── main.py # FastAPI 服务入口 ├── mcp_server.py # MCP 协议核心实现 ├── pr_generator.py # 生成 PR 描述的核心逻辑 ├── templates/ │ └── pr_description.md.j2 # Jinja2 模板 └── requirements.txt核心文件mcp_server.py关键代码from mcp.server.stdio import stdio_server from mcp.types import Tool, ToolResult, TextContent, ResourceContent from mcp.server.models import ( GetResourceResult, ListResourcesResult, CallToolResult, ) import asyncio import json from pr_generator import generate_pr_description # 定义工具 pr_describe_tool Tool( namepr_describe, descriptionGenerate a structured PR description from git diff and commit history, input_schema{ type: object, properties: { branch: { type: string, description: Target branch to compare against (e.g., main) }, jira_base_url: { type: string, description: Base URL for Jira (e.g., https://company.atlassian.net/browse/) } }, required: [branch] } ) async def pr_describe_handler(args: dict) - CallToolResult: 处理 pr_describe 工具调用 branch args[branch] jira_base_url args.get(jira_base_url, https://company.atlassian.net/browse/) try: # 调用核心生成逻辑 description_md await generate_pr_description(branch, jira_base_url) # 返回富媒体内容Markdown 文本 原始 JSON 数据供模型后续使用 return CallToolResult( content[ TextContent(typetext, textdescription_md), # 同时返回结构化数据方便模型做摘要或修改 TextContent( typetext, textfjson\n{json.dumps({branch: branch, generated_at: asyncio.get_event_loop().time()}, indent2)}\n ) ] ) except Exception as e: return CallToolResult( content[TextContent(typetext, textf❌ 生成失败{str(e)})] ) # 创建 MCP 服务器实例 server stdio_server( namepr-describer, version1.0.0, tools[pr_describe_tool], tool_handlers{pr_describe: pr_describe_handler}, )pr_generator.py的核心逻辑精简版import subprocess import re from jinja2 import Environment, FileSystemLoader from pathlib import Path def get_git_diff(branch: str) - dict: 获取分支对比的结构化信息 # 执行 git 命令获取变更文件 result subprocess.run( [git, diff, --name-status, forigin/{branch}...HEAD], capture_outputTrue, textTrue, checkTrue ) files [] for line in result.stdout.strip().split(\n): if not line: continue status, filepath line.split(\t, 1) files.append({status: status, path: filepath}) return {files: files} def extract_jira_ids(commit_msg: str) - list: 从提交信息中提取 Jira ID return re.findall(r[A-Z]-\d, commit_msg) async def generate_pr_description(branch: str, jira_base_url: str) - str: 主生成函数 # 1. 获取 Git 变更 diff_info get_git_diff(branch) # 2. 获取最近 5 条提交 commits_result subprocess.run( [git, log, -5, --prettyformat:%s|%H, forigin/{branch}...HEAD], capture_outputTrue, textTrue, checkTrue ) commits [] for line in commits_result.stdout.strip().split(\n): if | not in line: continue msg, sha line.split(|, 1) jira_ids extract_jira_ids(msg) commits.append({ message: msg, sha: sha[:7], jira_links: [f[{id}]({jira_base_url}{id}) for id in jira_ids] }) # 3. 渲染 Jinja2 模板 env Environment(loaderFileSystemLoader(templates)) template env.get_template(pr_description.md.j2) return template.render( branchbranch, commitscommits, diff_filesdiff_info[files], jira_base_urljira_base_url )templates/pr_description.md.j2模板## PR 概述 此 PR 旨在 {{ commits[0].message|truncate(50) }}。 ## ✨ 新增功能 {% for commit in commits %} {% if feat in commit.message or add in commit.message.lower() %} - {{ commit.message }} {% for link in commit.jira_links %}{{ link }} {% endfor %} {% endif %} {% endfor %} ## 修复问题 {% for commit in commits %} {% if fix in commit.message or bug in commit.message.lower() %} - {{ commit.message }} {% for link in commit.jira_links %}{{ link }} {% endfor %} {% endif %} {% endfor %} ## 依赖更新 {% if diff_files|selectattr(path, equalto, package.json)|list %} - 已更新 package.json 中的依赖项。 {% else %} - 无依赖变更。 {% endif %} ## ⚠️ 文件变更 {% for file in diff_files %} - {{ file.status }} {{ file.path }} {% endfor %}3.3 CLI 端配置安全、可靠、可维护将服务器接入 CLIsettings.json配置如下{ mcpServers: { pr-describer: { command: python, args: [-m, pr_describer.main], cwd: /Users/yourname/projects/pr-describer, env: { JIRA_API_TOKEN: $JIRA_API_TOKEN, GITHUB_TOKEN: $GITHUB_TOKEN }, timeout: 30000, trust: false, includeTools: [pr_describe] } } }关键配置解析cwd设为项目根目录确保./src/file.py能正确解析相对路径env使用$JIRA_API_TOKEN语法从 shell 环境变量读取避免密钥硬编码timeout: 3000030秒足够处理大型 diff又不至于让失败请求挂太久trust: false是安全底线每次调用都需确认includeTools: [pr_describe]是精准控制即使未来添加pr_review工具也不会意外暴露。启动与验证# 1. 在 pr-describer 目录下安装依赖 pip install -r requirements.txt # 2. 启动 CLI自动发现服务器 gemini # 3. 在 CLI 交互中执行 /mcp list # 应显示✅ pr-describer (CONNECTED) # 4. 调用工具首次会弹出确认框 /pr_describe --branchmain --jira_base_urlhttps://company.atlassian.net/browse/实测效果输入/pr_describe --branchdevelop几秒后返回结构化 Markdown包含自动提取的 Jira 链接、文件变更列表、按类型分类的提交摘要。复制粘贴到 GitHub PR 页面格式完美团队成员一致好评。注意/pr_describe是工具名不是 CLI 命令。CLI 会将其识别为 MCP 工具调用而非内置命令。如果你想让它像/mcp一样成为一级命令需在服务器端注册 MCP Prompt见第4节。4. MCP Prompt把复杂工作流封装成一句/prompt-name工具Tool解决“做什么”Prompt 解决“怎么说”。MCP Prompt 是 MCP 协议的另一面它让你把一整套复杂的、带参数的、多步骤的模型指令封装成一个可复用的 slash 命令。这比写工具更轻量却同样强大。4.1 Prompt 与 Tool 的本质区别维度ToolMCP Prompt执行主体外部程序Python/Node.js/ShellGemini 模型自身输入结构化 JSON 参数由模型生成用户输入的字符串经 CLI 解析为参数输出任意数据文本、JSON、图片、二进制模型生成的文本可含 Markdown、代码块适用场景需要访问外部系统DB、API、文件、执行副作用写文件、发邮件纯文本生成、格式转换、内容摘要、风格改写举个例子你想让模型把一段技术文档改写成面向产品经理的简洁版。用 Tool大材小用还得写个 Python 脚本调用模型 API。用 MCP Prompt一行配置搞定。4.2 构建一个实战 Prompt“技术文档转 PR 描述”我们创建一个 Prompt专门处理“从 JSDoc 注释生成 PR 描述”的场景。当开发者在代码中写了详细的 JSDoc我们想一键提取其核心变更点生成 PR 描述的## ✨ 新增功能部分。服务器端pr-describer项目中新增# 在 mcp_server.py 中添加 from mcp.types import Prompt # 定义 Prompt jsdoc_to_pr_prompt Prompt( namejsdoc-to-pr, titleJSDoc to PR Description, descriptionExtract key changes from JSDoc comments and format them as PR bullet points, args_schema{ type: object, properties: { jsdoc: { type: string, description: The raw JSDoc comment string } }, required: [jsdoc] } ) async def jsdoc_to_pr_handler(args: dict) - dict: Prompt 处理器返回一个包含 messages 的字典 jsdoc args[jsdoc] # 构建给模型的 prompt system_prompt You are an expert technical writer. Extract the core functional changes described in the JSDoc below. Output ONLY a bulleted list (using - ) of 1-3 concise, action-oriented points. Do NOT include any explanations, markdown headers, or code blocks. user_message fJSDoc:\njs\n{jsdoc}\n return { messages: [ {role: system, content: {type: text, text: system_prompt}}, {role: user, content: {type: text, text: user_message}} ] } # 将 Prompt 注册到服务器 server.register_prompt(jsdoc-to-pr, jsdoc_to_pr_prompt, jsdoc_to_pr_handler)CLI 端配置settings.json无需额外配置Prompt 会随服务器自动发现。使用方式在 CLI 交互中# 方式1带参数推荐 /jsdoc-to-pr --jsdoc/**\n * function calculateTotal\n * description Calculates the total price including tax.\n * param {number} subtotal - The subtotal amount before tax.\n * param {number} taxRate - The tax rate as a decimal (e.g., 0.08 for 8%).\n * returns {number} The total price.\n */ # 方式2位置参数简洁 /jsdoc-to-pr /**\n * function calculateTotal\n * description Calculates the total price including tax.\n * param {number} subtotal - The subtotal amount before tax.\n * param {number} taxRate - The tax rate as a decimal (e.g., 0.08 for 8%).\n * returns {number} The total price.\n */预期输出- 计算包含税额的总价 - 接收子总额和税率作为输入参数 - 返回计算后的总价数值4.3 Prompt 的进阶技巧参数默认值与组合调用MCP Prompt 支持zodschema因此可以定义默认值jsdoc_to_pr_prompt Prompt( namejsdoc-to-pr, titleJSDoc to PR Description, description..., args_schema{ type: object, properties: { jsdoc: {type: string}, style: { type: string, description: Output style: concise, detailed, or bullet, default: bullet # ← 默认值 } }, required: [jsdoc] } )这样用户可以省略--style参数直接用/jsdoc-to-pr --jsdoc...CLI 会自动传入style: bullet。更强大的是 Prompt 组合你可以先用/jsdoc-to-pr生成要点再用/pr_describe将其整合进完整 PR 描述。CLI 会自动将上一个 Prompt 的输出作为下一个工具的上下文。这就是工作流自动化的雏形——不是写死的脚本而是由模型动态编排的智能流水线。5. 生产环境避坑指南从配置冲突到 OAuth 失败的完整排查链路再完美的设计也会在生产环境露出獠牙。以下是我在真实项目中踩过的、文档里绝不会写的坑附带可复现的排查步骤。5.1 坑gemini mcp list显示DISCONNECTED但手动运行服务器命令一切正常现象gemini mcp list中pr-describer状态为DISCONNECTED但我在终端里执行cd /path/to/pr-describer python -m pr_describer.main能成功启动并响应curl http://localhost:8000/mcp/tools/list。排查链路必须按顺序检查工作目录cwd权限CLI 启动服务器时会cd到cwd指定的目录再执行命令。如果该目录对当前用户不可读ls -ld /path/to/pr-describer显示drwx------服务器进程会因无法读取requirements.txt或main.py而静默失败。解决方案chmod 755 /path/to/pr-describer。检查环境变量继承CLI 的env配置只传递指定变量不继承父进程的全部环境。如果你的服务器依赖PYTHONPATH或NODE_ENV它们不会自动存在。解决方案在env中显式添加或在服务器启动脚本中设置。检查 Stdio 传输的 stdin/stdout 缓冲Python 默认对sys.stdout做行缓冲当服务器输出{type: hello}后不换行CLI 会一直等待。解决方案在 Python 服务器中添加sys.stdout.reconfigure(line_bufferingTrue)或启动时加-u参数command: python, args: [-u, -m, pr_describer.main]。终极验证用--debug看 stderrgemini --debug启动触发/mcp list在 debug 日志中搜索stderr。你会看到服务器进程的完整错误输出比如ModuleNotFoundError: No module named jira——这才是真相。5.2 坑OAuth 认证失败/mcp auth打开浏览器后显示 “This site can’t be reached”现象配置了一个需要 Google OAuth 的远程 MCP 服务器执行/mcp auth my-server浏览器打开http://localhost:XXXX/oauth/callback但页面报错。根本原因与解决方案错误1本地端口被占用CLI 会随机选择一个空闲端口如54321但如果该端口被 Docker、其他服务占用回调会失败。解决方案在settings.json中为服务器指定固定端口redirectUri: http://localhost:8080/oauth/callback并确保8080端口空闲。错误2防火墙/杀毒软件拦截某些企业防火墙会阻止localhost的回环连接。解决方案临时关闭防火墙测试或改用127.0.0.1替代localhost在redirectUri中写http://127.0.0.1:8080/oauth/callback。错误3OAuth Client ID 未正确 allowlist这是最隐蔽的坑。Google Cloud Console 中IAPIdentity-Aware Proxy保护的服务要求 OAuth Client ID 必须在 IAP 的 “Allowlisted OAuth clients” 列表中。验证方法访问https://console.cloud.google.com/security/iap找到你的 Cloud Run 服务点击 “Edit” → “Allowlisted OAuth clients”确认你的 Client ID 在列表中。不在添加它等待 5 分钟生效。5.3 坑includeTools和excludeTools组合失效危险工具依然可用现象配置了excludeTools: [file_deleter]但模型仍能调用file_deleter。真相excludeTools的优先级虽高但它只作用于“已发现的工具”。如果服务器在tools/list响应中把工具名写成了delete_file而非file_deleterexcludeTools就匹配不上。解决方案用--debug查看 CLI 日志中tools/list的原始响应确认工具名完全一致。更稳妥的做法是在服务器端用server.registerTool(file_deleter, ...)显式注册确保名称可控。5.4 坑gemini mcp add添加的服务器在gemini mcp list中不显示现象gemini mcp add my-server python server.py执行成功但gemini mcp list无此服务器。原因gemini mcp add默认将服务器添加到project scope即当前目录下的.gemini/settings.json而gemini mcp list默认读取user scope~/.gemini/settings.json。解决方案加-s user参数gemini mcp add -s user my-server python server.py或明确用gemini mcp list -s project查看项目级配置。最后一个血泪教训永远不要在settings.json中写trust: true后就扔着不管。我曾因一个测试用的shell_exec工具服务器配置了trust: true后来忘记清理结果某次模型误判执行了rm -rf ./node_modules。从此我的trust: true只存在于localhost的、无网络访问能力的、沙箱化的 Python 环境中。安全不是功能是每一次trust前的深呼吸。