1. 项目概述API密钥安全管理的十字路口在当今这个API驱动的开发世界里API密钥就像是开启数据宝库的“数字钥匙”。无论是调用大语言模型、连接云服务还是集成第三方支付密钥的安全直接关系到应用的核心资产与用户隐私。然而很多开发者包括我自己在早期都曾陷入一个看似简单的选择困境拿到一个API密钥后是应该让客户端应用直接用它去请求服务商即“直连”还是应该在自己的服务器上架设一个中间层来代为转发请求即“中转”这个问题远非“哪个更好”那么简单它背后牵扯到安全、成本、性能、运维复杂度等一系列工程权衡。最近在社区里我看到不少讨论都围绕着具体问题展开有人抱怨“vscode里claude code插件总报api error”在反复排查“到底是密钥、网络还是配置搞错了”有人则在研究“codex中转api”或寻找“tavo免费api密钥”这类资源还有人在处理类似“请求已被站点的安全策略拦截”或“win11组织安全策略阻止未经验证的来宾访问”这类底层网络或系统策略问题。这些零散的问题其实都指向了API调用链路中“密钥安全策略”这个核心议题。直连方案简单粗暴但密钥暴露风险高中转方案增加了控制力却也引入了新的复杂性和单点故障。这篇文章我就结合自己多年在前后端架构和安全攻防方面的实战经验为你彻底拆解这两种策略不搞理论空谈只讲能直接落地的方案、踩过的坑和具体的选择依据。2. 核心概念与风险模型拆解在深入对比之前我们必须先统一认知明确我们在讨论什么以及我们要防范什么。这就像打仗前得先看清地图和敌情。2.1 什么是API密钥它为何如此脆弱API密钥本质上是一串用于身份验证和授权的凭证。对于大多数云服务商如OpenAI、AWS、Google Cloud来说你用它来证明“我是我”并据此计费和进行权限控制。它的脆弱性源于其设计初衷为了方便机器与机器之间的通信。它不像用户密码那样可以定期更换或通过多因素认证加固一旦泄露攻击者就可以在密钥失效前如果设置了过期时间或在你发现并吊销前以你的身份和配额为所欲为。一个常见的误区是将API密钥等同于密码认为只要不写在客户端代码里就安全。实际上任何能接触到客户端代码或网络流量的人都可能提取出密钥。在浏览器开发者工具的“网络”选项卡中一个粗心的Authorization: Bearer sk-xxx请求头暴露无遗。因此API密钥安全的第一原则是永远不要将高权限的、长期有效的密钥交付给不可信的环境尤其是前端客户端。2.2 直连模式便捷与风险并存直连模式顾名思义就是客户端应用Web前端、移动App、桌面软件直接持有API密钥并以其身份向最终的服务提供商发起请求。典型流程开发者从服务商控制台获取API密钥如sk-xxx。将该密钥硬编码或通过环境变量配置到客户端应用中。客户端在需要时直接将密钥放入请求头如Authorization: Bearer sk-xxx发送请求至服务商端点如https://api.openai.com/v1/chat/completions。服务商验证密钥处理请求并返回结果。优点显而易见架构简单没有中间环节开发调试快速。延迟低请求路径最短理论上响应最快。成本低无需维护额外的服务器资源。但其风险是致命且难以缓解的密钥完全暴露密钥存储在客户端意味着任何能访问客户端代码或进行逆向工程的人都能获取它。即使你做了代码混淆通过抓包工具拦截网络请求也能轻易拿到。权限失控客户端持有的密钥通常需要具备完成其功能的所有权限。一旦泄露攻击者就拥有了同等权限。难以审计和限流服务商看到的请求都来自同一个密钥你无法区分哪些是合法用户请求哪些是攻击者滥用的请求。虽然服务商可能提供基于IP的限流但对抗分布式攻击或单个恶意客户端效果有限。吊销与轮换困难一旦发现泄露你需要立即吊销密钥并更换。这意味着所有客户端都需要更新对于已分发的桌面应用或移动App来说几乎是灾难性的。注意有些开发者尝试用“环境变量”或“配置文件”来管理客户端密钥认为这比硬编码安全。这本质上只是将密钥从代码仓库移到了部署环境但密钥最终仍需被加载到客户端内存中暴露风险并未降低。这只解决了代码仓库泄露的问题没有解决运行时泄露的问题。2.3 中转模式构筑安全防线中转模式也称为API网关模式或反向代理模式其核心思想是引入一个自己完全掌控的中间服务器。客户端不再直接持有服务商的API密钥而是向你的中转服务器发送请求中转服务器验证客户端身份后附上服务商API密钥代为转发请求并将结果返回给客户端。典型流程开发者将服务商API密钥安全地存储在中转服务器上如服务器环境变量、密钥管理服务。客户端不持有服务商密钥而是持有另一个用于访问你自家中转服务器的凭证可以是简单的令牌、JWT甚至是一套完整的用户认证体系。客户端向你的中转服务器端点发起请求如https://your-proxy.com/v1/chat。中转服务器验证客户端身份、进行权限检查、请求限流、日志记录等。验证通过后中转服务器将请求转发至服务商真实端点并在请求头中填入服务商API密钥。将服务商的响应原样或经过处理后返回给客户端。这种模式的优势在于安全性的根本提升密钥不落地客户端服务商密钥永远在你的服务器端从根本上杜绝了客户端泄露的风险。精细化的访问控制你可以为不同客户端或用户分配不同的令牌并实施细粒度的权限策略例如用户A只能调用模型A每天最多10次。集中审计与监控所有API调用都经过你的服务器你可以完整记录谁、在什么时候、调用了什么、消耗了多少token便于分析和异常检测。灵活的请求处理可以在中转层实现请求/响应改写、参数校验、格式转换、缓存、重试、降级等逻辑。密钥轮换无感更换服务商API密钥时只需在中转服务器更新客户端完全不受影响。当然它引入了新的复杂性和考量点架构复杂需要设计、开发、部署和维护一个高可用的中转服务。成本增加产生了额外的服务器或Serverless成本、带宽成本。延迟增加请求多了一跳网络传输理论上会增加延迟但通过优化和同地域部署可以做到影响甚微。单点故障风险你的中转服务器成了新的关键节点其可用性直接决定了整个服务的可用性。3. 实战架构设计与技术选型理解了核心概念我们进入实战环节。我将分别展示两种模式下的典型架构并给出具体的技术选型建议。这里不会推荐某个具体的“tavo免费api密钥”或“中转api平台”而是教你如何自己搭建稳健的体系。3.1 直连模式的“极限”加固方案虽然直连模式风险高但在某些对延迟极度敏感、或资源极其有限如IoT设备的场景下可能不得不考虑。如果必须直连那么我们的目标是将风险降到最低。架构思路核心是“最小权限”和“短期有效”。不要使用那个拥有全部权限的根密钥。使用临时密钥STS许多云服务商如AWS、阿里云提供了安全令牌服务STS可以颁发临时访问凭证。这些凭证有效期很短如15分钟到1小时且权限受限。客户端在启动时先向一个安全的令牌颁发服务由你控制请求临时密钥。这个颁发服务需要严格的身份认证。这是最推荐的加固方案。密钥分域与限流如果服务商支持创建多个仅具备必要权限的API密钥用于不同的客户端或功能模块。并在服务商控制台为每个密钥设置严格的速率限制和额度告警。客户端代码混淆与加固使用工具对前端JavaScript或移动端二进制文件进行混淆、压缩、加固增加逆向工程和静态分析的难度。但这只是增加攻击成本并非绝对安全。请求签名如果服务商支持对于某些服务可以对请求内容进行签名密钥用于生成签名而非直接传输。但这通常需要服务商SDK的支持。技术栈示例前端直连场景一个简单的浏览器端Demo需要调用OpenAI API。极不推荐的做法在JavaScript中写死sk-xxx。相对好一点的做法仍不完美// 假设你有一个非常简单的、用于颁发一次性令牌的端点 async function getTemporaryToken() { // 这个端点本身必须有严格的认证如IP白名单、简单密码防止被滥用 const resp await fetch(/api/get-temp-token, { method: POST }); const data await resp.json(); return data.token; // 假设这个token是短期有效的 } async function callOpenAI(messages) { const tempToken await getTemporaryToken(); const response await fetch(https://api.openai.com/v1/chat/completions, { method: POST, headers: { Content-Type: application/json, Authorization: Bearer ${tempToken} // 使用临时令牌 }, body: JSON.stringify({ model: gpt-3.5-turbo, messages: messages, // 务必在服务端对tempToken关联的密钥进行模型、额度等限制 }) }); return await response.json(); }实操心得即使这样临时令牌也会在客户端内存和网络请求中暴露。这个/api/get-temp-token端点本身如果防护不足会成为攻击入口。因此这只是一个“比完全暴露根密钥好一点”的权宜之计适用于内部工具或风险极低的场景绝不适用于生产级面向公众的应用。3.2 中转模式的稳健实现方案对于绝大多数生产环境尤其是面向公众的Web或移动应用中转模式是必须的。下面是一个中等复杂度的可落地架构。架构核心组件客户端可以是Web、App、小程序等。它只与你的中转服务器通信。认证网关负责验证客户端身份。可以是简单的API Key也可以是OAuth 2.0 / JWT等。建议为每个客户端或用户分配唯一标识。中转服务器业务核心接收客户端请求进行业务逻辑处理鉴权、限流、计费、日志然后转发至上游服务商。上游服务商如OpenAI、Anthropic等AI服务或其他第三方API。数据库/缓存用于存储用户配额、调用日志、限流计数器等。密钥管理服务安全地存储和管理上游服务商的API密钥。绝对不要将密钥硬编码在代码或配置文件中提交到代码库。技术选型建议语言与框架选择你团队熟悉的、生态良好的语言。Node.js (Express/Fastify)、Python (FastAPI/Flask)、Go (Gin) 都是优秀选择性能好、开发效率高。部署与运维传统服务器使用Nginx/Apache作为反向代理处理SSL、负载均衡。应用服务器部署在后面。需要自行管理服务器、监控、扩缩容。容器化使用Docker封装应用通过Kubernetes或Docker Compose编排提升可移植性和伸缩性。Serverless对于流量波动大或希望极致简化运维的场景AWS Lambda、Google Cloud Functions、Vercel/Netlify Functions是绝佳选择。你只需编写转发逻辑平台负责一切运维。这是目前我个人最推荐给中小项目的起步方案。密钥管理云服务商密钥管理AWS Secrets Manager, Google Cloud Secret Manager, Azure Key Vault。它们提供自动轮换、版本控制、细粒度访问策略。开源方案HashiCorp Vault。功能强大但运维复杂。初级方案严格使用环境变量并通过dotenv等库在开发中加载在生产中由部署平台如PM2、systemd、Docker注入。确保.env文件在.gitignore中。限流与监控限流在网关或应用层实现。可以使用express-rate-limit(Node.js)、slowapi(Python)等中间件基于客户端标识进行限流如每秒N次每天M次。监控与日志集成Sentry、Logtail等工具记录错误和调用日志。使用PrometheusGrafana或云厂商的监控服务来观察QPS、延迟、错误率。一个简单的Node.js (Express) Serverless (Vercel) 中转示例// api/proxy/chat.js (Vercel Serverless Function 路径) import axios from axios; import rateLimit from express-rate-limit; import slowDown from express-slow-down; // 应用级限流针对整个function较粗糙 const limiter rateLimit({ windowMs: 15 * 60 * 1000, // 15分钟 max: 100, // 每个IP限制100次请求 message: 请求过于频繁请稍后再试。 }); // 减速器让频繁请求变慢 const speedLimiter slowDown({ windowMs: 15 * 60 * 1000, delayAfter: 50, // 50次请求后开始减速 delayMs: 500 // 每次请求增加500ms延迟 }); export default async function handler(req, res) { // 1. 应用限流中间件Vercel环境下需稍作调整此处为逻辑示意 // await applyMiddleware(req, res, [limiter, speedLimiter]); // 2. 客户端认证示例简单的API Key校验 const clientApiKey req.headers[x-api-key]; if (!clientApiKey || clientApiKey ! process.env.CLIENT_API_KEY) { return res.status(401).json({ error: 无效的客户端API Key }); } // 3. 业务逻辑检查用户配额这里简化直接从环境变量读取实际应从数据库查 const userQuota parseInt(process.env.USER_DAILY_QUOTA) || 10; // 应有逻辑查询该clientApiKey对应的用户今日已用次数此处省略... // if (usedToday userQuota) { return res.status(429).json({error: 今日额度已用尽}); } // 4. 获取并验证请求体 const { messages, model } req.body; if (!messages || !Array.isArray(messages)) { return res.status(400).json({ error: 无效的请求参数: messages }); } // 5. 准备转发给上游的请求 const openaiApiKey process.env.OPENAI_API_KEY; // 从Vercel环境变量安全读取 const upstreamUrl https://api.openai.com/v1/chat/completions; try { const upstreamResponse await axios.post(upstreamUrl, { model: model || gpt-3.5-turbo, messages: messages, max_tokens: 500, }, { headers: { Authorization: Bearer ${openaiApiKey}, Content-Type: application/json, }, timeout: 30000, // 设置超时 }); // 6. 记录成功日志此处可写入数据库或日志服务 console.log([SUCCESS] Client: ${clientApiKey}, Model: ${model}, Tokens: ${upstreamResponse.data.usage?.total_tokens}); // 7. 将上游响应返回给客户端 res.status(200).json(upstreamResponse.data); } catch (error) { // 8. 错误处理与日志 console.error([ERROR] Client: ${clientApiKey}, error.response?.data || error.message); // 将上游服务的错误信息有选择地返回给客户端避免泄露内部细节 const statusCode error.response?.status || 500; const errorMessage error.response?.data?.error?.message || 上游服务请求失败; res.status(statusCode).json({ error: errorMessage, // 可附加一个不敏感的错误ID用于追踪 error_id: Date.now() }); } }实操心得这个示例部署在Vercel上无需管理服务器。关键点在于1) 使用环境变量OPENAI_API_KEY和CLIENT_API_KEY管理密钥2) 实现了基础的客户端认证3) 有结构化的错误处理和日志记录。这是生产可用的起点。接下来你需要补充数据库来管理用户配额、实现更完善的限流、并添加更详细的审计日志。4. 安全加固与高级策略无论是直连还是中转安全都是一个多层次、持续的过程。下面分享一些超越基础方案的高级加固策略和实战中积累的经验。4.1 中转模式下的纵深防御当中转服务器成为核心后它自身的安全就是重中之重。输入验证与净化永远不要信任客户端输入。除了检查messages数组还要验证每个message的角色和内容长度防止注入攻击或资源耗尽攻击如发送超长内容消耗你的token。// 示例简单的输入验证 function validateMessages(messages) { if (!Array.isArray(messages) || messages.length 0) { throw new Error(Messages must be a non-empty array.); } for (const msg of messages) { if (![system, user, assistant].includes(msg.role)) { throw new Error(Invalid message role: ${msg.role}); } if (typeof msg.content ! string || msg.content.length 10000) { throw new Error(Message content must be a string and less than 10000 chars.); } // 可根据需要过滤敏感词或特殊字符 } return true; }输出过滤与脱敏同样不要直接将上游API的响应原样返回。检查响应中是否包含你不希望客户端看到的敏感信息如上游API的内部错误详情、其他用户的潜在信息泄露等。对于AI模型还可以设置内容过滤器拦截违规输出。基于令牌的细粒度权限不要一个客户端API Key走天下。实现一个简单的令牌系统每个令牌关联一个用户ID、权限集如允许的模型列表、最大token数和速率限制。每次请求都校验令牌的有效性和权限。请求签名与防重放对于高安全要求的场景可以让客户端对请求进行签名。客户端使用一个预共享的Secret不同于API Key和请求参数、时间戳生成签名。服务器端用同样的算法验证签名并检查时间戳防止重放攻击如5分钟内的请求有效。这能有效防止请求在传输中被篡改。IP白名单与地理封锁在中转服务器或前面的WAFWeb应用防火墙上可以设置只允许特定IP段如你的办公网络、云服务IP访问管理接口或者屏蔽来自高风险地区的访问。4.2 密钥全生命周期管理密钥管理不是设置一次就完事了。创建与存储最小权限原则在服务商控制台创建密钥时只赋予它完成目标所需的最小权限。例如如果只用于聊天就不要给图像生成权限。安全存储立即将密钥存入密钥管理服务或环境变量。绝对不要将密钥写入代码、提交到Git、或通过聊天工具发送。很多泄露源于开发者在测试时不小心将带密钥的代码推到了公开仓库。分发与使用访问控制确保只有需要使用的服务如你的中转服务器有权限读取密钥。在云平台上这通过IAM角色或资源策略实现。在代码中引用永远通过环境变量或SDK从安全存储中读取密钥。# Python示例错误做法 api_key sk-123456789 # 绝对禁止 # Python示例正确做法 import os api_key os.environ.get(OPENAI_API_KEY) if not api_key: raise ValueError(请设置 OPENAI_API_KEY 环境变量)轮换与吊销定期轮换为关键密钥制定轮换策略如每90天。使用密钥管理服务的自动轮换功能最佳。泄露响应建立监控告警如异常额度消耗。一旦怀疑泄露立即在服务商控制台吊销该密钥并在所有使用它的地方更新为新密钥。这就是中转模式的优势——只需更新服务器一处。监控与审计日志记录详细记录所有密钥的使用情况时间、来源IP、操作、消耗资源。这些日志要集中存储并设置告警规则。额度监控密切关注API使用量和费用。设置消费预算告警防止因密钥泄露或程序bug导致“天价账单”。4.3 应对特定场景与陷阱场景“vscode里claude code插件总报api error”这通常是典型的客户端直连配置问题。首先检查插件中配置的API端点Endpoint和密钥是否正确。其次很多此类插件默认直连境外服务可能受网络波动或策略影响。一个解决方案是如果该插件支持自定义API地址你可以将其配置为你自己的中转服务器地址由中转服务器去连接Claude API从而绕过客户端的网络问题。陷阱“请求已被站点的安全策略拦截”这可能是浏览器CORS跨源资源共享策略导致的。如果你的前端页面托管在https://your-app.com而直接请求https://api.openai.com浏览器会因为同源策略而阻止。直连模式必须面对CORS问题而服务商不一定为你开启CORS。中转模式则完美解决前端请求同源的https://your-app.com/api/proxy由服务器端不受CORS限制去请求上游API。网络问题如“两台交换机通过隧道直连 怎么通过管理ip让两者实现ntp授时请求呢”这类问题虽然不直接相关但提醒我们基础设施的连通性至关重要。确保你的中转服务器与上游API服务商之间的网络稳定、低延迟。选择地理上靠近上游服务商的云区域部署你的中转服务可以显著降低延迟。5. 决策指南与成本效益分析读到这里你可能已经对两种策略的优劣有了清晰认识。但在具体项目中如何选择呢我总结了一个决策框架你可以从以下几个维度评估评估维度直连模式中转模式分析与建议安全性要求极低高涉及用户数据、付费服务、核心业务逻辑必须选中转。内部工具、一次性脚本可考虑直连但仍需加固。客户端环境可控性高低/高均可如果客户端是完全受控的内部桌面应用可内置强认证直连风险稍低。对于浏览器、移动App等不可控环境直连风险极高。性能与延迟最优略增对延迟有极致要求如实时游戏、高频交易且能接受安全妥协可评估直连。对于大多数应用中转增加的几十到几百毫秒延迟是可接受的。通过同地域部署、优化代码可将额外延迟控制在极低水平。开发与运维成本低高直连几乎无额外开发成本。中转需要设计、开发、部署、监控和维护一个服务。但对于团队来说这是一个有价值的基础设施投资长期看能降低安全事件处理成本和提升管理效率。功能灵活性低高中转层让你可以轻松添加缓存、A/B测试、请求改写、多服务商负载均衡、统一计费鉴权等功能而无需改动客户端。适用阶段原型验证、内部Demo生产环境、公开服务快速验证想法时可用直连。一旦进入生产或对外服务应尽快迁移至中转架构。成本效益分析直接成本中转模式增加了服务器/Serverless成本、带宽成本流量经过你的服务器、以及开发和维护的人力成本。风险成本潜在损失直连模式的风险成本是未知且可能极高的。一次密钥泄露可能导致1) 巨额API费用2) 敏感数据泄露3) 服务被滥用导致账号被封禁4) 企业声誉损失。这个成本远高于搭建和维护一个中转服务的成本。结论对于任何严肃的、计划长期运营的项目中转模式的安全收益和功能灵活性几乎总是超过其增加的复杂性和直接成本。它带来的集中管控、安全提升和业务扩展能力是直连模式无法比拟的。6. 常见问题排查与实战技巧在实际操作中你会遇到各种各样的问题。这里我整理了一份从实战中总结的排查清单和技巧。6.1 问题排查清单当你遇到API调用失败时可以按照以下路径排查客户端错误4xx401 Unauthorized认证失败。直连检查API密钥是否正确、是否已过期或被吊销。检查请求头格式Bearer后面有空格。中转检查客户端传递给中转服务器的认证信息如X-API-Key是否正确。检查中转服务器自身的认证逻辑。403 Forbidden权限不足。检查该API密钥是否具备执行当前操作的权限例如尝试用只读密钥进行写操作。检查是否触发了服务商或你自己设置的IP黑名单、区域限制。429 Too Many Requests速率限制。直连触发了服务商对该密钥的全局速率限制。需要降低调用频率或申请提升限额。中转可能是你的中转服务器对客户端的限流也可能是你中转服务器对上游的请求触发了上游的限流。查看相关日志确认。400 Bad Request请求参数错误。仔细检查请求体JSON格式、字段名、字段类型、必填项。使用JSON验证工具。特别是messages数组的结构是否符合API要求。服务器端错误5xx502 Bad Gateway/504 Gateway Timeout网关错误。中转模式常见你的中转服务器无法连接到上游服务或上游服务响应超时。检查中转服务器的网络出口、防火墙规则、DNS解析。增加上游请求的超时时间。500 Internal Server Error内部服务器错误。中转模式可能是你的中转服务器代码有未处理的异常。查看服务器日志。直连上游服务商内部故障。查看服务商状态页。网络与连接问题“到底是密钥、网络还是配置搞错了?”这是最经典的困惑。系统化排查第一步验证密钥。用同一个密钥使用最简单的工具如curl命令或Postman直接测试上游API。如果成功说明密钥和网络没问题问题在你的客户端代码或配置。第二步验证网络。如果curl也失败检查网络连通性ping、telnet端口、代理设置、DNS。对于国内访问境外API网络波动是常态这就是中转的价值——你可以在境外部署中转服务器国内客户端连接国内或亚洲的中转节点中转节点连接境外API稳定性更好。第三步验证配置。检查端点URL、请求方法、Headers、Body格式是否完全符合API文档。一个字符的错误都可能导致失败。6.2 实战技巧与避坑指南密钥分级管理创建多个密钥用于不同环境开发、测试、生产。生产环境密钥权限要收窄。为不同的微服务或功能模块创建不同的密钥实现权限隔离。这样即使一个密钥泄露影响范围也有限。使用API网关或专门的中转服务如果业务复杂不要自己从零写中转服务器。考虑使用Kong、Tyk、Apache APISIX等开源API网关它们内置了认证、限流、监控、日志等大量功能。对于AI API市面上也有提供托管中转服务的平台如一些“API聚合平台”它们帮你处理了密钥管理和负载均衡。但需要仔细评估其安全性、可靠性、隐私政策和成本避免将鸡蛋放在别人的篮子里。实现优雅降级与熔断在中转服务器中如果上游API连续失败或超时应实现熔断机制如使用oresilient或circuitbreaker库暂时停止向上游发送请求直接向客户端返回友好错误防止雪崩。准备后备方案例如当主要AI服务不可用时可以降级到另一个备用服务或者返回缓存的通用应答。详尽的日志记录记录每一次转发的请求和响应注意脱敏不要记录完整的API密钥或敏感消息内容。记录客户端IP、用户ID、请求时间、模型、消耗token数、响应时间、状态码。这些日志是排查问题、分析用量、检测异常如某个用户突然暴增的调用量的黄金数据。预算与用量告警在服务商控制台和你的中转服务器监控里都设置用量和费用告警。例如当日用量达到月额度的80%时发送邮件或短信告警。在中转层实现“软额度”控制当用户接近其配额时提前拒绝请求避免超支。API密钥安全管理是一场攻防战没有一劳永逸的银弹。直连模式如同在闹市街头用保险箱运钞看似直接高效实则危机四伏中转模式则像建立了自己的武装押运体系和金库虽然前期投入大但为你的核心资产构建了可控的防御纵深。从我经历过的项目来看早期为了省事采用直连而后期因泄露被迫紧急迁移的代价远大于从一开始就设计中转架构。希望这篇结合了原理、实战和踩坑经验的解析能帮你做出更明智的架构选择并搭建起一个既安全又高效的API调用体系。记住安全是一种习惯从写下第一行调用代码时就应该开始。
)
