1. 这不是“调个接口”那么简单Web API 在 Python 3 中的真实战场“Como Utilizar APIs Web no Python 3”——这个葡萄牙语标题直译是“如何在 Python 3 中使用 Web API”但如果你真把它当成一个简单的“三行代码调用接口”的入门教程那接下来的项目大概率会在第三天凌晨两点卡死在ConnectionResetError或者429 Too Many Requests的报错上。我带过二十多个 Python 开发新人几乎所有人第一次独立对接生产环境 API 时都栽在同一个地方他们以为自己在写 Python其实是在和整个互联网基础设施打交道。APIs Web 不是 Python 的一个函数库它是一扇门门后是 DNS 解析、TLS 握手、HTTP/1.1 与 HTTP/2 的流控差异、服务端限流策略、JSON Schema 的隐式契约、以及你永远猜不到的上游服务降级逻辑。Python 3 提供的是requests这把瑞士军刀但真正决定你能不能把门推开的是你对 Web 协议栈的理解深度。这个标题背后藏着的是 Python 开发者从“写脚本”迈向“构建网络应用”的分水岭。它适合谁适合所有已经能用print()和for循环处理本地文件但第一次面对https://api.example.com/v1/users这个 URL 时心里发虚、不知道该先查文档还是先装pip install requests的人也适合那些已经用过几次 API却总在超时、重试、认证失败、数据解析异常上反复踩坑的中级开发者。核心关键词 APIs Web、Python、Python 3、Web每一个都不是孤立存在Python 是你的工具语言Python 3 是你必须依赖的运行时环境因为asyncio、typing等关键特性只在此版本成熟Web 定义了协议边界与交互范式而 APIs Web 则是这三者交汇处最锋利、也最易割伤手指的那把刀。接下来的内容不会教你“第一步 pip install第二步 import requests”而是带你亲手拆开这把刀看清它的刃口角度、钢材热处理工艺以及——更重要的是当你用力过猛时它会从哪个方向崩裂。2. 整体设计思路为什么不用 urllib为什么必须用 Python 3以及“简单”背后的三重陷阱2.1 为什么坚决放弃 urllib而选择 requests或 httpx很多老派 Python 教程还在用urllib.request理由是“标准库不用装”。这在十年前或许成立但在今天坚持用urllib就像坚持用 DOS 命令行写现代 GUI 应用。urllib的核心问题不是功能缺失而是心智负担转移。它把本该由库处理的复杂性赤裸裸地甩给了你。比如一个看似简单的 GET 请求# urllib 版本 —— 你需要自己处理的细节 import urllib.request import urllib.parse import ssl url https://api.example.com/data params {page: 1, limit: 20} query_string urllib.parse.urlencode(params) full_url f{url}?{query_string} # 1. 你得手动构造 URL 编码 # 2. 你得自己处理 HTTPS 的 SSL 上下文否则在某些企业内网会直接失败 context ssl.create_default_context() req urllib.request.Request(full_url) # 3. 你得自己加 headers否则很多 API 直接返回 403 req.add_header(User-Agent, MyApp/1.0) req.add_header(Accept, application/json) try: with urllib.request.urlopen(req, contextcontext) as response: # 4. 你得自己 decode 字节流还得猜编码格式 data response.read().decode(utf-8) # 5. 你得自己检查状态码 if response.getcode() ! 200: raise Exception(fHTTP {response.getcode()}) # 6. 你得自己解析 JSON import json result json.loads(data) except urllib.error.HTTPError as e: # 7. 错误处理分支极其分散 print(fHTTP Error: {e.code} - {e.reason})而requests的等效代码是# requests 版本 —— 复杂性被封装你只关注业务逻辑 import requests url https://api.example.com/data params {page: 1, limit: 20} # 一行构造、自动编码、自动处理 HTTPS、自动设置常见 headers response requests.get(url, paramsparams, timeout10) # 一行检查状态码可选但推荐 response.raise_for_status() # 一行解析 JSON自动处理编码 result response.json()这不是语法糖的胜利这是抽象层次的胜利。requests把你从协议细节中解放出来让你能聚焦于“我要什么数据”和“拿到数据后做什么”。这就是为什么在 Python 3 生态中requests是事实上的 Web API 交互标准。当然对于高并发场景httpx支持异步正快速成为新宠但其设计哲学一脉相承让开发者远离底层 HTTP 细节。2.2 为什么必须是 Python 3Python 2 的“遗产”有多沉重标题里明确写着 “Python 3”这绝非偶然。Python 2 在 2020 年已正式退役但它的幽灵仍在一些旧教程里游荡。坚持用 Python 3 的核心原因有三个且每一个都直击 Web API 开发的痛点第一Unicode 处理的彻底重构。Python 2 的str类型是字节串unicode类型才是文本。当你从 API 拿到一个包含中文、emoji 或特殊符号的 JSON 响应时requests返回的response.text在 Python 2 下极易因编码推断失败而抛出UnicodeDecodeError。你不得不写一堆response.content.decode(utf-8)或更复杂的chardet探测逻辑。Python 3 彻底解决了这个问题str就是 Unicode 文本bytes就是字节流界限清晰。response.text默认就是正确解码后的字符串response.content就是原始字节。这种“开箱即用”的正确性省去了大量调试时间。第二asyncio和aiohttp的成熟。现代 Web API 调用尤其是需要批量拉取数据如爬取 100 个用户信息时同步阻塞是性能杀手。Python 3.5 引入的async/await语法配合aiohttp库可以轻松实现并发请求。下面是一个对比# 同步方式耗时约 10 秒假设每个请求 100ms import requests urls [fhttps://api.example.com/user/{i} for i in range(100)] for url in urls: response requests.get(url) process_user(response.json()) # 异步方式耗时约 100-200ms取决于网络和服务器并发能力 import asyncio import aiohttp async def fetch_user(session, url): async with session.get(url) as response: return await response.json() async def main(): urls [fhttps://api.example.com/user/{i} for i in range(100)] async with aiohttp.ClientSession() as session: tasks [fetch_user(session, url) for url in urls] results await asyncio.gather(*tasks) for user in results: process_user(user) asyncio.run(main())没有 Python 3 的asyncio这种量级的性能提升根本无法优雅实现。第三类型提示Type Hints的普及。Python 3.5 引入的typing模块让 API 响应数据结构的定义变得可验证。你可以这样写from typing import List, Dict, Optional import requests def get_users() - List[Dict[str, Optional[str]]]: response requests.get(https://api.example.com/users) response.raise_for_status() return response.json() # IDE 和 mypy 可以据此检查你后续对 users 的操作是否安全 users get_users() for user in users: # IDE 知道 user 是 dict且 key 是 strvalue 可能是 str 或 None name user.get(name) # 安全 # age user[age] # IDE 会警告可能 KeyError因为 age 不在类型定义中这极大地提升了大型项目中 API 集成的健壮性和可维护性。Python 2 完全不具备这种能力。2.3 “简单使用”背后的三重陷阱超时、重试、认证很多初学者认为“调用 API”就是requests.get(url)。但现实是网络是不可靠的服务是会抖动的API 是有规矩的。忽略以下三点你的代码在本地测试完美在生产环境必然崩溃。陷阱一没有超时timeout的请求是定时炸弹。requests默认不设超时这意味着如果目标服务器宕机或网络路由出现黑洞你的程序会无限期挂起直到操作系统 TCP 层的超时通常是几分钟。这在 Web 服务中是灾难性的会导致连接池耗尽、线程阻塞、最终服务雪崩。必须显式设置timeout。更佳实践是分开设置连接超时connect和读取超时read# 好分离 connect 和 read 超时更精细控制 response requests.get( url, timeout(3.05, 27) # (connect_timeout, read_timeout) ) # 差单一超时值无法区分是连不上还是数据读太慢 # response requests.get(url, timeout30)陷阱二没有重试retry机制的请求是脆弱的。网络抖动、服务端瞬时过载都会导致502 Bad Gateway、503 Service Unavailable或504 Gateway Timeout。这些错误往往是暂时的。requests本身不提供重试但urllib3requests的底层依赖提供了强大的Retry对象。一个健壮的客户端应该这样配置from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry session requests.Session() # 配置重试策略最多重试 3 次指数退避只对特定状态码重试 retry_strategy Retry( total3, status_forcelist[429, 500, 502, 503, 504], method_whitelist[HEAD, GET, OPTIONS, POST], backoff_factor1 # 第一次重试等待 1s第二次 2s第三次 4s ) adapter HTTPAdapter(max_retriesretry_strategy) session.mount(http://, adapter) session.mount(https://, adapter) # 现在用 session 发起的请求都自带重试 response session.get(url)陷阱三忽略认证Authentication的请求是无效的。绝大多数生产 API 都需要某种形式的认证。常见的有API Key通过headers传递如{X-API-Key: your-key-here}Bearer Token通过headers传递如{Authorization: Bearer your-jwt-token}Basic Authrequests提供了便捷的auth参数requests.get(url, auth(username, password))硬编码密钥是严重安全风险。正确的做法是将密钥存于环境变量并在代码中读取import os import requests API_KEY os.getenv(MY_API_KEY) # 从环境变量读取 if not API_KEY: raise ValueError(Environment variable MY_API_KEY is not set) headers {X-API-Key: API_KEY} response requests.get(url, headersheaders)这三重陷阱——超时、重试、认证——构成了 Web API 使用的“基础生存包”。跳过任何一个你的代码就只是实验室里的玩具而非生产环境的武器。3. 核心细节解析从请求构造到响应解析的全流程实操要点3.1 构造一个“生产就绪”的请求Headers、Params、Data、JSON 的精确分工一个看似简单的requests.get()调用背后是 HTTP 协议的精密分工。理解params、data、json、headers各自的职责是避免 400 Bad Request 的关键。params专用于 URL 查询参数Query String这是 GET、HEAD、OPTIONS 请求的“标配”。它会自动进行 URL 编码确保空格变成%20中文变成%E4%B8%AD%E6%96%87。# 正确构造 ?qpythonwebsortcreatedorderdesc params { q: python web, sort: created, order: desc } response requests.get(https://api.github.com/search/repositories, paramsparams)提示不要试图把params用在 POST 请求的 body 里。那是data或json的领地。headersHTTP 请求头是你的“身份名片”和“行为声明”这是最容易被忽视却最常导致失败的部分。两个核心头必须设置User-Agent: 很多 API尤其是公开的会拒绝来自python-requests/2.x这种默认 UA 的请求认为是爬虫。你应该设置一个描述你应用的 UA。Accept: 明确告诉服务器你期望接收什么格式的数据。对于 JSON API必须是application/json。headers { User-Agent: MyAwesomeApp/1.0 (contactmyapp.com), Accept: application/json, Content-Type: application/json # 如果你要发送 JSON 数据这个头也必须有 } response requests.get(url, headersheaders)datavsjsonPOST/PUT 请求的 Body 之争这是新手最大的混淆点。data接收的是字节串或字典json接收的是Python 对象并会自动序列化为 JSON 字符串并设置Content-Type头。# 方式一用 data 手动序列化不推荐容易出错 import json payload {name: John, email: johnexample.com} response requests.post( url, datajson.dumps(payload), # 手动转 JSON 字符串 headers{Content-Type: application/json} # 必须手动设头 ) # 方式二用 json 参数强烈推荐 payload {name: John, email: johnexample.com} # requests 会自动1. json.dumps(payload) 2. 设置 Content-Type: application/json response requests.post(url, jsonpayload)注意json参数只适用于application/json。如果你要上传文件或发送application/x-www-form-urlencoded表单数据则必须用data并传入字典requests会自动编码或字节串。实操心得我曾经在一个项目中因为误用了data而不是json导致 API 服务器收到的是一个未解析的字符串{name: John}而不是一个 JSON 对象结果所有字段都解析为空。花了整整一个下午才定位到这个“小”错误。记住口诀“发 JSON用json发表单用data发文件用files。”3.2 响应解析不只是response.json()还有状态码、Headers、Cookies 的深度利用拿到response对象后response.json()只是冰山一角。一个成熟的开发者会系统性地检查所有可用信息。状态码Status CodeHTTP 的“健康报告单”永远不要假设response.status_code 200。必须检查。requests提供了response.raise_for_status()方法它会在状态码表示错误4xx 或 5xx时抛出异常这是最简洁的检查方式。try: response requests.get(url) response.raise_for_status() # 如果是 404, 500 等这里就抛异常了 data response.json() except requests.exceptions.HTTPError as e: # 处理具体的 HTTP 错误 if response.status_code 404: print(资源不存在) elif response.status_code 401: print(认证失败请检查 API Key) else: print(fHTTP 错误: {e}) except requests.exceptions.RequestException as e: # 处理网络错误、超时等 print(f请求异常: {e})响应头Response Headers隐藏的宝藏服务器通过响应头告诉你很多重要信息Content-Type: 确认你收到的数据格式防止response.json()因内容不是 JSON 而崩溃。X-RateLimit-Limit,X-RateLimit-Remaining,X-RateLimit-Reset: API 限流的关键指标。你可以据此动态调整你的请求频率避免被封禁。Link: 分页 API 的导航链接如 GitHub API用于获取下一页数据。response requests.get(https://api.github.com/users/octocat/repos?page1per_page30) # 检查限流 remaining int(response.headers.get(X-RateLimit-Remaining, 0)) reset_time int(response.headers.get(X-RateLimit-Reset, 0)) if remaining 10: # 剩余配额不多了可以睡一会再继续 import time sleep_seconds max(0, reset_time - time.time()) time.sleep(sleep_seconds 1) # 解析分页链接 link_header response.headers.get(Link) if link_header: # Link: https://api.github.com/users/octocat/repos?page2per_page30; relnext import re next_match re.search(r([^]); relnext, link_header) if next_match: next_url next_match.group(1) # 获取下一页Cookies会话状态的载体对于需要登录的 Web API如某些内部管理后台requests.Session()会自动帮你管理 Cookies。Session对象就像一个浏览器标签页它会记住服务器返回的Set-Cookie并在后续请求中自动带上。session requests.Session() # 第一步登录获取 Cookies login_data {username: admin, password: secret} login_response session.post(https://api.example.com/login, datalogin_data) login_response.raise_for_status() # 第二步后续所有请求都自动携带登录态的 Cookies user_response session.get(https://api.example.com/user/profile) user_response.raise_for_status()实操心得有一次我需要对接一个老旧的内部系统它的 API 文档里完全没提 Cookies只说“登录后即可访问”。我花了两天时间用curl -v抓包才发现在登录响应头里有一个Set-Cookie: JSESSIONIDxxx。没有Session每次请求都得手动提取并设置这个 Cookie极其繁琐。Session是这类有状态 API 的生命线。3.3 错误处理与日志让每一次失败都成为可追溯的线索在生产环境中一个静默失败的 API 调用比一个抛出异常的调用更可怕。因此错误处理的核心原则是捕获、记录、分类、通知。捕获覆盖所有可能的异常类型requests的异常体系非常清晰你应该按层次捕获import logging import requests from requests.exceptions import ( Timeout, ConnectionError, HTTPError, RequestException ) logger logging.getLogger(__name__) def safe_api_call(url): try: response requests.get(url, timeout(3, 10)) response.raise_for_status() return response.json() except Timeout: logger.error(f请求超时: {url}) # 可以触发告警或返回缓存数据 return None except ConnectionError: logger.critical(f连接错误网络或服务不可达: {url}) # 这是严重故障可能需要人工介入 return None except HTTPError as e: # 4xx 错误通常是客户端问题参数错、权限不足 if 400 e.response.status_code 500: logger.warning(f客户端错误 ({e.response.status_code}): {url} - {e}) # 5xx 错误通常是服务端问题服务宕机、Bug elif 500 e.response.status_code 600: logger.error(f服务端错误 ({e.response.status_code}): {url} - {e}) return None except RequestException as e: # 兜底捕获所有 requests 异常 logger.exception(f未知请求异常: {url} - {e}) return None记录日志必须包含上下文一条好的日志应该能让你在不看代码的情况下复现问题。至少包含时间戳、请求 URL、请求方法、状态码、错误消息、以及如果可能请求 ID如果 API 支持的话。# 在异常处理中添加更多上下文 except HTTPError as e: logger.error( fAPI 调用失败 | fURL: {url} | fMethod: GET | fStatus: {e.response.status_code} | fResponse: {e.response.text[:200]} | # 记录前200字符的响应体便于排查 fRequest-ID: {e.response.headers.get(X-Request-ID, N/A)} )分类与通知建立错误等级制度不是所有错误都需要发邮件告警。你应该建立一个分级制度CRITICAL:ConnectionError意味着整个服务链路中断必须立即通知。ERROR:500内部服务器错误持续发生时需告警。WARNING:400、401、403通常是客户端配置问题记录即可高频出现时再告警。INFO: 成功的请求记录 URL 和耗时用于性能监控。实操心得我在一个电商项目中曾将429 Too Many Requests错误记录为WARNING结果发现每天有上万次。这说明我们的限流策略有问题或者某个下游 API 的配额设置得太低。这个“警告”最终帮助我们优化了整个数据同步流程将 API 调用次数降低了 40%。错误日志不是噪音它是系统的脉搏。4. 实操过程从零开始构建一个健壮的 GitHub 用户信息抓取器4.1 环境准备与依赖安装Python 3 的最小化可靠环境在开始编码前一个干净、隔离、可复现的 Python 3 环境是基石。我强烈反对直接在系统 Python 或全局pip中安装包。步骤一创建虚拟环境Virtual Environment这是 Python 3 的标准实践它为你创建一个独立的、与系统和其他项目隔绝的 Python 环境。# 确保你有 Python 3.8 或更高版本 python3 --version # 创建一个名为 venv 的虚拟环境名字可自定义 python3 -m venv venv # 激活虚拟环境Linux/macOS source venv/bin/activate # 激活虚拟环境Windows venv\Scripts\activate.bat # 激活后你的命令行提示符前会显示 (venv)表示已进入该环境步骤二升级 pip 并安装核心依赖虚拟环境创建后pip可能是旧版本先升级。# 升级 pip pip install --upgrade pip # 安装 requests核心 HTTP 客户端 pip install requests # 安装 python-dotenv用于管理环境变量安全存储 API Key pip install python-dotenv # 可选安装 rich用于美化终端输出提升开发体验 pip install rich为什么不用 condaconda是一个优秀的包和环境管理器尤其在数据科学领域。但对于纯 Web API 开发venvpip是 Python 官方推荐、最轻量、兼容性最好的组合。conda create -n pytorch_env python3.9这类命令是为 PyTorch 这样的大型科学计算框架设计的它会安装一整套 C/C 编译工具链和数学库对于一个简单的 API 客户端来说完全是杀鸡用牛刀且会显著增加环境初始化时间。步骤三创建项目结构一个清晰的结构是项目长期可维护的保障。github-user-fetcher/ ├── .env # 存放敏感环境变量API Key ├── requirements.txt # 依赖清单用于一键复现环境 ├── main.py # 主程序入口 ├── api_client.py # 封装所有 API 交互逻辑 ├── models.py # 定义数据模型如 User 类 └── utils.py # 工具函数如日志配置、重试装饰器4.2 核心模块实现api_client.py的工业级封装api_client.py是整个项目的“心脏”。它不应该只是一个requests.get()的包装而应该是一个具备重试、超时、认证、日志、错误分类的完整客户端。# api_client.py import logging import os import time from typing import Optional, Dict, Any, List import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry from dotenv import load_dotenv # 加载环境变量 load_dotenv() # 配置日志 logging.basicConfig( levellogging.INFO, format%(asctime)s - %(name)s - %(levelname)s - %(message)s ) logger logging.getLogger(__name__) class GitHubAPIClient: 一个健壮的 GitHub API 客户端 def __init__(self, base_url: str https://api.github.com): self.base_url base_url self.session requests.Session() # 1. 配置重试策略 retry_strategy Retry( total3, status_forcelist[429, 500, 502, 503, 504], allowed_methods[HEAD, GET, OPTIONS, POST, PUT, DELETE], backoff_factor1 ) adapter HTTPAdapter(max_retriesretry_strategy) self.session.mount(http://, adapter) self.session.mount(https://, adapter) # 2. 设置默认 headers self.session.headers.update({ User-Agent: GitHubUserFetcher/1.0 (github.com/yourusername), Accept: application/vnd.github.v3json }) # 3. 从环境变量加载 API Token如果有的话用于提高配额 token os.getenv(GITHUB_TOKEN) if token: self.session.headers.update({ Authorization: ftoken {token} }) logger.info(GitHub Token 已加载将使用认证配额) else: logger.warning(GitHub Token 未设置将使用未认证配额60次/小时) def _make_request(self, method: str, endpoint: str, **kwargs) - requests.Response: 统一的请求方法添加超时和日志 url f{self.base_url}{endpoint} # 设置默认超时 kwargs.setdefault(timeout, (3.05, 27)) logger.debug(f发起 {method} 请求: {url}) start_time time.time() try: response self.session.request(method, url, **kwargs) duration time.time() - start_time logger.info(f{method} {url} - {response.status_code} (耗时: {duration:.2f}s)) # 记录限流信息 remaining response.headers.get(X-RateLimit-Remaining) if remaining: logger.debug(f剩余配额: {remaining}) return response except requests.exceptions.RequestException as e: duration time.time() - start_time logger.error(f{method} {url} 失败 - {e} (耗时: {duration:.2f}s)) raise def get_user(self, username: str) - Optional[Dict[str, Any]]: 获取单个用户信息 try: response self._make_request(GET, f/users/{username}) response.raise_for_status() return response.json() except requests.exceptions.HTTPError as e: if e.response.status_code 404: logger.warning(f用户 {username} 不存在) return None raise except requests.exceptions.RequestException as e: logger.error(f获取用户 {username} 时发生网络错误: {e}) return None def search_users(self, query: str, per_page: int 30, page: int 1) - Optional[Dict[str, Any]]: 搜索用户 params {q: query, per_page: per_page, page: page} try: response self._make_request(GET, /search/users, paramsparams) response.raise_for_status() return response.json() except requests.exceptions.RequestException as e: logger.error(f搜索用户 {query} 时发生错误: {e}) return None # 创建一个全局客户端实例方便在其他模块中导入使用 client GitHubAPIClient()这个模块的设计体现了前面提到的所有最佳实践重试、超时、日志、环境变量管理、错误分类。它不是一个“玩具”而是一个可以直接投入生产的组件。4.3 主程序与数据模型main.py与models.py的协同main.py是程序的入口它负责协调各个模块处理用户输入并展示结果。# main.py import sys from typing import List, Dict, Any from rich.console import Console from rich.table import Table from rich.progress import track from api_client import client from models import User console Console() def display_user(user: User): 用 rich 库美化输出用户信息 table Table(show_headerTrue, header_stylebold magenta) table.add_column(字段, styledim, width12) table.add_column(值) table.add_row(用户名, user.login) table.add_row(姓名, user.name or N/A) table.add_row(公司, user.company or N/A) table.add_row(位置, user.location or N/A) table.add_row(公共仓库数, str(user.public_repos)) table.add_row(关注者数, str(user.followers)) table.add_row(URL, user.html_url) console.print(table) def main(): if len(sys.argv) 2: console.print([red]用法: python main.py username[/red]) console.print(例如: python main.py octocat) return username sys.argv[1] console.print(f[bold blue]正在查询用户: {username}...[/bold blue]) # 调用 API 客户端 user_data client.get_user(username) if not user_data: console.print(f[red]未找到用户 {username}。[/red]) return # 将原始字典数据映射为 User 模型对象 user User(**user_data) # 展示结果 display_user(user) if __name__ __main__: main()models.py则负责数据的结构化和类型安全它利用了 Python 3.7 的dataclass和typing。# models.py from dataclasses import dataclass from typing import Optional, List, Dict, Any dataclass class User: GitHub 用户数据模型 login: str id: int node_id: str avatar_url: str gravatar_id: str url: str html_url: str followers_url: str following_url: str gists_url: str starred_url: str subscriptions_url: str organizations_url: str repos_url: str events_url: str received_events_url: str type: str site_admin: bool name: Optional[str] None company: Optional[str] None blog: Optional[str] None location: Optional[str] None email: Optional[str] None hireable: Optional[bool] None bio: Optional[str] None twitter_username: Optional[str] None public_repos: int 0 public_gists: int 0 followers: int 0 following: int 0 created_at: str updated_at: str classmethod def from_dict(cls, data: Dict[str, Any]) - User: 从字典创建 User 实例处理键名映射和类型转换 # GitHub API 的字段名和 dataclass 字段名可能不完全一致这里做映射 # 例如API 返回 twitter_username而 dataclass 字段是 twitter_username # 这里是简化版实际项目中可能需要更复杂的映射逻辑 return cls(**data)4.4 运行与测试从本地调试到生产部署的平滑过渡本地调试# 1. 激活虚拟环境 source venv/bin/activate # 2. 运行程序 python main.py octocat你会看到一个漂亮的、带颜色的表格输出octocat的信息。同时控制台也会打印详细的 DEBUG 日志告诉你每一步发生了什么。生成依赖清单为了确保团队其他成员或 CI/CD