1. 项目概述一个独立开发者用错开发工具的真实代价八个月前我亲手把第一个 Web 应用推上了生产环境——一个基于 Flask 的轻量级数据看板后端跑在 Python 3.9 上前端用 Bootstrap Chart.js部署在一台 2 核 4G 的云服务器上。整个项目从零开始没团队、没 CI/CD 流程、没 DevOps 工程师就我一个人写代码、调接口、修 bug、配 Nginx、改防火墙、看日志、回用户邮件。当时我毫不犹豫地装了 Visual Studio 2019理由很“体面”它名气大、图标蓝得稳重、听说能“企业级开发”而且我大学时用过 VS 做 C# 课设感觉“熟悉安全”。结果呢这八个月里我至少花了 67 小时在和 VS 2019 较劲——不是写业务逻辑而是绕开它、哄着它、给它打补丁、查它报的莫名其妙的错误。这不是效率问题是方向性误判。DevOps 工具的本质从来不是功能多不多而是“你动一下它跟不跟得上你换台机器它能不能立刻复现你凌晨三点收到告警它能不能让你三秒定位到哪行代码漏了空格”。对于单人项目、MVP 验证、快速迭代型 Web 应用尤其是 Flask/Django/FastAPI/Node.js 这类脚本驱动型服务VS 2019 不是“重型装备”是套不合身的宇航服——看着专业一抬手就卡肘关节。而 Visual Studio Code不是“轻量替代品”它是为今天这种“一人即全栈、本地即产线、提交即部署”的开发现实量身定制的操作系统。关键词里的DevOps Tool在这里不是指 Jenkins 或 GitLab CI 那种管道引擎而是指你每天打开、敲下第一行代码、保存、运行、调试、提交、部署、查日志所依赖的那个“数字工作台”本身是否天然支持 DevOps 的最小原子操作——自动化、可复现、低认知负荷、跨环境一致。这篇文章不讲 VS 2019 多差也不吹 VS Code 多神只讲我在真实项目中踩过的每一个坑、算过的每一笔时间账、对比过的每一条配置路径。如果你正打算启动一个个人 Web 项目或者带小团队做快速验证又或者被现有开发环境拖慢节奏——这篇就是为你写的实操复盘。2. 内容整体设计与思路拆解为什么“大厂标配”在个人项目里反而是负资产2.1 核心矛盾工具设计哲学与个体开发节奏的根本错位VS 2019 的设计原点非常清晰服务 .NET 生态下的大型企业级应用。这意味着它的所有核心模块——解决方案Solution结构、项目文件.csproj/.vbproj、构建系统MSBuild、调试器C# CLR 调试深度集成、测试框架MSTest/NUnit 深度绑定、发布向导ClickOnce/Web Deploy——全部围绕一个前提运转代码必须严格归属某个“项目”项目必须有明确的编译目标exe/dll构建过程必须可重复、可审计、可由多人协同触发。它默认假设你有 TFS/Azure DevOps 作为源码和构建中枢有专职 QA 跑自动化测试有运维团队维护 IIS。而我的 Flask 项目呢它没有“编译”概念。flask run就是启动pip install -r requirements.txt就是依赖管理git push到 GitHub 后GitHub Actions 自动拉取、安装、测试、部署。VS 2019 强行要把app.py塞进一个.pyproj文件里再生成一堆obj/和bin/目录还试图用 MSBuild 去“编译” Python——这就像给自行车装涡轮增压不仅没用还会让链条崩断。我试过用 VS 2019 的 Python 工作负载它确实能识别.py文件但当你右键“调试”时它默认启动的是一个封装了python.exe的调试宿主进程这个宿主会劫持sys.path、注入自己的调试钩子、甚至修改os.environ。结果就是本地能跑通的flask run --reload在 VS 里调试时 reload 失效用dotenv加载的.env变量在 VS 调试环境下路径解析错乱更绝的是它会把venv/Scripts/activate.bat当成普通脚本执行而不是激活环境——导致你实际在全局 Python 下运行却以为在虚拟环境中。这不是 Bug是设计必然。因为 VS 的“环境管理”逻辑是为 .NET 的global.json和 SDK 版本切换设计的不是为 Python 的venv或poetry设计的。2.2 DevOps 视角下的三大不可逆损耗时间、确定性、可迁移性我把这八个月的损耗归结为三个可量化的维度时间损耗非增值操作的隐形税我统计了前两个月的日常操作耗时样本56 次典型开发循环在 VS 2019 中打开解决方案 → 等待 Solution Explorer 加载平均 8.3 秒→ 手动选择正确的 Python 环境VS 不自动识别 venv需每次从下拉菜单选平均 4.1 秒→ 右键app.py→ “调试” → 等待调试器附加平均 6.7 秒→ 修改代码 → CtrlS → 等待 VS 自动重启它不支持 Flask 的--reload必须手动停止再启动平均 3.2 秒。单次启动修改循环平均耗时 22.3 秒。在 VS Code 中打开文件夹 → CtrlShiftP 输入Python: Select Interpreter→ 选中venv/bin/python首次后自动记住→ F5 启动自动读取.vscode/launch.json→ 修改代码 → CtrlS → Flask 自动 reload1 秒。单次循环平均耗时 3.8 秒。表面上看每次快 18 秒但一天 30 次就是 9 分钟一个月就是 4.5 小时。这还没算 VS 偶尔卡死、需要强制结束进程、丢失未保存更改的额外时间。确定性损耗环境漂移带来的“薛定谔的 Bug”VS 2019 的 Python 环境管理是“黑盒式”的。它会在%LOCALAPPDATA%\Microsoft\VisualStudio\16.0_xxx\Extensions\下创建私有 site-packages 缓存并把你的requirements.txt里某些包比如click替换成它自己打包的版本。结果就是你在 VS 里调试一切正常但用命令行python app.py启动或者部署到服务器后click版本冲突flask run命令直接报错。我花了整整一个下午排查最后发现是 VS 把click8.0锁死在了8.0.1而服务器上的pip install装的是8.1.3两者对get_current_context()的返回值处理不同。这种问题无法用pip freeze复现因为 VS 的环境根本不走标准pip流程。而 VS Code 的环境管理是“白盒式”的它只做一件事——把python.pythonPath指向你指定的venv/bin/python剩下的完全交给pip和python本身。你pip list看到什么VS Code 就用什么。确定性是 DevOps 的基石而 VS 2019 在个人项目里亲手把它凿穿了。可迁移性损耗项目脱离 VS 就“失能”VS 2019 生成的.sln和.pyproj文件本质是微软私有格式。它们包含大量 IDE 特有的元数据窗口布局、断点位置、最近打开文件列表、甚至字体大小。这些文件一旦提交到 Git就会污染仓库。我最初把.sln提交上去结果同事用 PyCharm克隆后根本打不开报错Unsupported project type。后来我学乖了.sln不提交但这就带来新问题新成员或我自己换电脑必须重新创建解决方案、手动添加文件、重新配置环境——整个项目失去了“开箱即用”的能力。而 VS Code 的项目状态全部存在.vscode/文件夹里且全是 JSON/Markdown 等纯文本格式。settings.json控制缩进和格式化launch.json定义调试配置tasks.json定义构建任务extensions.json记录推荐插件。这些文件可以、也应该提交到 Git。新成员git clone后code .打开VS Code 自动提示“检测到推荐扩展是否安装”点击确认环境就 100% 复现。这才是 DevOps 所说的“基础设施即代码”IaC在开发环境层面的落地——你的编辑器配置本身就是可版本化、可审计、可自动化的基础设施。2.3 为什么 VS Code 成为现代 Web 开发的“默认选项”不是因为它多好而是因为它足够“无感”很多人问“VS Code 到底强在哪” 我的答案很直白它强在“不抢戏”。它不试图定义你的工作流而是让你定义它。VS 2019 的工作流是预设的创建项目 → 编写代码 → 构建 → 调试 → 发布。VS Code 的工作流是空白的你打开一个文件夹 → 它问“需要我帮你配置 Python 环境吗” → 你选“是” → 它生成launch.json→ 你改两行 → 完事。它的所有强大都建立在“不干预”之上。比如调试VS 2019 的调试器是“一体机”你只能接受它提供的视图和行为VS Code 的调试器是“乐高”你通过launch.json的configurations数组可以自由组合用request: launch启动 Flask用request: attach连接已运行的 Gunicorn 进程用preLaunchTask: pip install在调试前自动装依赖用envFile: ${workspaceFolder}/.env精确加载环境变量。这些不是 VS Code 内置的功能而是它开放的 API 和标准化的协议Debug Adapter Protocol允许社区插件实现的。所以 VS Code 的生态不是“微软造的”是“全世界开发者一起搭的”。当你需要 Docker 支持装Docker插件需要 Kubernetes装Kubernetes插件需要 Terraform装HashiCorp Terraform插件。所有这些都共享同一套 UI、同一套快捷键、同一套配置体系。而 VS 2019 的插件是“寄生”在它的庞大躯体上的每个插件都要适配它的 COM 接口、它的 UI 框架、它的生命周期管理开发成本高、更新慢、体验割裂。这就是为什么一个 2023 年的新手搜索“如何调试 Flask”前 10 条结果有 9 条指向 VS Code 配置而搜索“VS 2019 调试 Flask”结果大多是 Stack Overflow 上 2018 年的过期问答标题写着“Workaround for Python Tools for Visual Studio (PTVS) not supporting Flask reload”。3. 核心细节解析与实操要点从 VS 2019 的“舒适陷阱”到 VS Code 的“精准控制”3.1 环境管理从“VS 的魔法黑盒”到“你的 venv 全权掌控”VS 2019 的 Python 环境管理本质上是一个“模拟层”。它不直接调用你的venv/bin/python而是启动一个叫ptvsdPython Tools for Visual Studio Debug的代理进程这个进程再 fork 出真正的 Python 解释器。好处是它能深度介入调试过程比如断点命中时冻结整个解释器状态坏处是它完全绕过了 Python 的标准启动流程。最典型的症状就是PYTHONPATH和sys.path的混乱。举个真实例子我的项目结构是my-flask-app/ ├── app.py ├── requirements.txt ├── config.py └── utils/ └── helpers.py在app.py里我写了from utils.helpers import do_something。在命令行里只要cd my-flask-app python app.py就能跑通。但在 VS 2019 里它会报ModuleNotFoundError: No module named utils。为什么因为 VS 默认把my-flask-app/当作工作目录Working Directory但它启动ptvsd时会把my-flask-app/加到sys.path的末尾而不是开头。而utils/模块的导入依赖于my-flask-app/在sys.path[0]。解决方案网上教的方法是在 VS 的“调试属性”里手动设置“工作目录”为$(ProjectDir)再在“环境变量”里加一行PYTHONPATH$(ProjectDir)。但这只是治标。更深层的问题是VS 的“Python 环境”设置里那个下拉菜单列出的“Python 3.9 (venv)”根本不是你venv/bin/python的真实路径而是 VS 自己缓存的一个符号链接。你pip install新包后VS 不会自动刷新这个缓存必须手动点击“刷新环境”按钮——而这个按钮藏在“工具 Python Python 环境”里三级菜单。我有三次因为忘了刷新导致调试时用的还是旧版requests线上请求超时本地却一切正常。VS Code 的解法简单粗暴且符合 Python 原教旨它不做任何翻译只做路径映射。步骤只有三步打开项目文件夹code my-flask-appCtrlShiftP→ 输入Python: Select Interpreter→ 在弹出的列表里找到并选择./venv/bin/pythonWindows 是.\venv\Scripts\python.exeVS Code 会自动生成.vscode/settings.json内容为{ python.defaultInterpreterPath: ./venv/bin/python }从此VS Code 的所有 Python 相关操作——语法检查、代码补全、调试、终端启动——都 100% 使用这个路径指向的解释器。pip list是什么它就用什么python -c import sys; print(sys.path)输出什么它的sys.path就是什么。没有中间商没有代理层没有缓存。你venv/bin/python -m pip install flask2.2.5下一秒CtrlShiftP→Python: Restart Language Server补全就立刻生效。这种“所见即所得”的确定性是 VS 2019 永远无法提供的因为它违背了其“企业级管控”的设计初衷——VS 必须保留一层抽象以便未来对接 Azure DevOps 的策略引擎、对接 SCCM 的合规检查。而你一个独立开发者不需要策略引擎你只需要import flask不报错。提示VS Code 的 Python 插件会自动检测项目根目录下的venv/、.venv/、env/等常见虚拟环境文件夹。如果你习惯用poetry它也能识别poetry.lock并提示你使用poetry env info --path获取解释器路径。这种“约定优于配置”的哲学让工具真正服务于人而不是让人去适应工具。3.2 调试体验从“VS 的重型坦克”到“VS Code 的手术刀”VS 2019 的调试器像一辆装甲厚重的坦克火力猛支持内存转储、线程堆栈全览但转向笨拙启动慢、reload 失效、地形适应差对 Flask/Gunicorn/uWSGI 等 Web 服务器模型支持生硬。它的核心限制在于它把“调试”等同于“单进程阻塞式执行”。Flask 的--reload机制是靠watchdog库监听文件变化然后 fork 出一个新进程来替换旧进程。VS 2019 的调试器只能 attach 到一个进程当旧进程被 kill新进程起来调试器就断开了你得手动重新 attach。更麻烦的是--reload模式下Flask 的主进程parent和工作进程child是分离的。VS 2019 默认 attach 到 parent但你真正想 debug 的业务逻辑都在 child 进程里。要让它 attach 到 child得在launch.jsonVS 2019 不叫这个名字叫“调试设置”里勾选“启用子进程调试”但这选项在 Python 工作负载里是灰色的因为 PTVS 不支持。最终方案放弃--reload用flask run --no-reload然后每次改完代码手动按CtrlBreak停止再按F5重启——这已经不是调试是体力劳动。VS Code 的调试是模块化、可组合的。它的核心是launch.json一个纯 JSON 配置文件放在.vscode/下。针对 Flask我的配置是{ version: 0.2.0, configurations: [ { name: Python: Flask, type: python, request: launch, module: flask, env: { FLASK_APP: app.py, FLASK_ENV: development }, args: [ run, --no-debugger, --no-reload, --port, 5000 ], jinja: true, justMyCode: true } ] }关键点解析module: flask告诉调试器不要运行app.py而是运行python -m flask。这是 Flask 官方推荐的启动方式确保FLASK_APP环境变量被正确读取。args数组显式传递--no-reload因为我们不需要 VS Code 去模拟 reload它做不到而是用另一个插件解决——Auto Reload。这个插件监听文件保存事件自动发送SIGINT给当前运行的flask run进程然后重新执行F5。整个过程无缝比 VS 2019 的手动重启快 5 倍。jinja: true启用 Jinja2 模板调试。当你的 HTML 模板里有{% if user.is_admin %}这样的逻辑VS Code 可以在模板里设断点停在那一行查看user对象的所有属性。VS 2019 完全不支持 Jinja2它只认.py文件。justMyCode: true这是最关键的性能开关。它让调试器只在你的代码里停跳过所有site-packages里的库代码如flask/app.py,werkzeug/serving.py。否则一个简单的return render_template(index.html)调试器会先停在render_template函数内部再停在jinja2/environment.py里再停在os/path.py里…… 10 行业务代码200 行库代码调试心智负担爆炸。VS 2019 没有这个开关它的“仅限我的代码”选项对 Python 是无效的。注意VS Code 的调试配置是“一次编写处处运行”。我把这个launch.json提交到 Git我的树莓派、我的 Mac、我的同事的 Windows 笔记本只要装了 Python 插件F5就能启动无需任何额外配置。而 VS 2019 的“调试设置”是存储在用户目录下的二进制文件里无法版本化无法共享。3.3 DevOps 集成从“VS 的发布向导”到“VS Code 的 GitCI 全链路”VS 2019 的“发布”功能是为 .NET Web Forms 或 ASP.NET MVC 设计的。它有一个图形化的“发布向导”引导你选择目标IIS、FTP、Azure App Service然后生成一个.pubxml文件里面是 XML 格式的发布配置。对于 Flask这个向导根本不会出现。你只能手动右键项目 → “发布”然后它会报错“无法为 Python 项目生成发布配置”。官方文档建议的方案是用命令行dotnet publish—— 但dotnet publish是为 .NET Core 设计的对 Python 无效。最终我被迫回到命令行写了一个publish.bat脚本内容是echo off setlocal cd /d %~dp0 call venv\Scripts\activate.bat pip install -r requirements.txt xcopy app.py ..\prod-server\ /Y xcopy templates\ ..\prod-server\templates\ /E /Y这已经不是 DevOps这是“手工部署”。更讽刺的是VS 2019 的 Git 集成是它最鸡肋的部分。它把 Git 当作“源码版本管理器”而不是“CI/CD 触发器”。你Ctrl0, CtrlG打开 Git 工具窗口可以 commit、push、pull但它不会在你push到main分支时自动触发pip install -r requirements.txt systemctl restart my-flask-app。它不会告诉你这次 commit 是否通过了单元测试除非你手动配置 MSBuild 调用pytest但那又是另一套复杂配置。它只是一个 GUI 包装器底层还是调用git.exe。VS Code 的 DevOps 集成是“声明式”的。它不提供 GUI 向导而是让你用标准文件定义一切Git 操作内置的 Source Control 视图和命令行git完全一致。CtrlShiftP→Git: Commit它调用的就是git commit。你看到的 diff就是git diff的输出。没有抽象层没有意外。CI/CD 触发.github/workflows/deploy.yml。这是我用的完整配置name: Deploy to Production on: push: branches: [main] paths: - **.py - requirements.txt - templates/** - static/** jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkoutv3 - name: Set up Python uses: actions/setup-pythonv4 with: python-version: 3.9 - name: Install dependencies run: | python -m pip install --upgrade pip pip install -r requirements.txt - name: Run tests run: pytest tests/ - name: Deploy to server uses: appleboy/scp-actionmaster with: host: ${{ secrets.HOST }} username: ${{ secrets.USERNAME }} key: ${{ secrets.KEY }} source: app.py, requirements.txt, templates/, static/ target: /var/www/my-flask-app/ - name: Restart service uses: appleboy/ssh-actionmaster with: host: ${{ secrets.HOST }} username: ${{ secrets.USERNAME }} key: ${{ secrets.KEY }} script: | cd /var/www/my-flask-app sudo systemctl restart my-flask-app这个 YAML 文件就是我的 DevOps 流水线。它和 VS Code 无关但 VS Code 的 GitHub Pull Requests 插件能让我在编辑器里直接看到 PR 的 CI 状态、评论、批准情况。当我pushGitHub Actions 自动运行当它失败VS Code 的 Problems 面板会高亮显示pytest的失败用例当我修复push后Problems 面板自动刷新。整个链路没有 VS 2019 那种“发布向导”的幻觉只有代码、配置、自动化。这才是 DevOps 的本来面目用代码定义流程用工具执行流程用反馈闭环优化流程。VS 2019 试图用 GUI 封装流程结果封装掉了透明度和可控性VS Code 用文本文件暴露流程反而赢得了灵活性和可靠性。4. 实操过程与核心环节实现一份可直接抄作业的 VS Code Flask 开发环境搭建指南4.1 环境初始化5 分钟完成从零到可调试这不是理论是我今天早上2023年7月24日在一台全新 Ubuntu 22.04 虚拟机上实测的步骤全程录像无剪辑。目标创建一个能立即调试、带单元测试、可一键部署的 Flask 项目。步骤 1基础环境安装2 分钟# 更新系统 sudo apt update sudo apt upgrade -y # 安装 Python 3.9 和 pipUbuntu 22.04 默认是 3.10但 Flask 2.2.x 对 3.10 有兼容问题 sudo apt install -y python3.9 python3.9-venv python3.9-dev python3-pip # 设置 pip 为默认可选但推荐 sudo update-alternatives --install /usr/bin/python3 python3 /usr/bin/python3.9 1 # 安装 Git 和 curl后续部署用 sudo apt install -y git curl步骤 2创建项目骨架30 秒# 创建项目目录 mkdir my-flask-app cd my-flask-app # 初始化 Git git init # 创建虚拟环境注意用 python3.9 显式指定避免歧义 python3.9 -m venv venv # 激活环境 source venv/bin/activate # 升级 pip pip install --upgrade pip # 安装 Flask 和测试依赖 pip install flask pytest pytest-cov # 创建基本文件 touch app.py requirements.txt tests/test_app.py步骤 3编写最简 Flask 应用1 分钟app.py内容from flask import Flask, render_template app Flask(__name__) app.route(/) def home(): return Hello from VS Code! app.route(/health) def health(): return {status: ok}, 200 if __name__ __main__: app.run(debugTrue, host0.0.0.0, port5000)requirements.txt内容生成pip freeze requirements.txt # 内容应为Flask2.2.5, Werkzeug2.2.3, ...步骤 4VS Code 配置3 分钟下载并安装 VS Codehttps://code.visualstudio.com/启动 VS CodeCtrlShiftP→Extensions: Install Extensions搜索并安装Pythonby MicrosoftPylanceby Microsoft提供智能补全Auto Reloadby yuichinukiyama自动重启 FlaskGitLensby Eric Amodio增强 Git 功能CtrlShiftP→Python: Select Interpreter→ 选择./venv/bin/pythonCtrlShiftP→Developer: Generate Configuration Files→ 选择Python→ 自动生成.vscode/settings.json手动创建.vscode/launch.json内容如下复制粘贴即可{ version: 0.2.0, configurations: [ { name: Python: Flask, type: python, request: launch, module: flask, env: { FLASK_APP: app.py, FLASK_ENV: development }, args: [ run, --no-debugger, --no-reload, --port, 5000 ], jinja: true, justMyCode: true } ] }CtrlShiftP→Tasks: Configure Task→Create tasks.json file from template→Others编辑为{ version: 2.0.0, tasks: [ { label: Run Tests, type: shell, command: pytest tests/ -v --covapp --cov-reporthtml, group: build, presentation: { echo: true, reveal: always, focus: false, panel: new, showReuseMessage: true, clear: true } } ] }步骤 5第一次调试30 秒F5启动调试VS Code 底部状态栏显示Python: Flask终端输出* Running on http://0.0.0.0:5000打开浏览器访问http://localhost:5000看到Hello from VS Code! 在home()函数第一行加断点点击行号左侧刷新页面VS Code 自动停住可查看app对象、request对象CtrlShiftP→Tasks: Run Build Task→Run Tests终端运行pytest输出测试报告。至此一个完整的、可调试、可测试、可部署的 Flask 开发环境5 分钟内搭建完毕。所有配置文件.vscode/下都可提交到 Git新成员git clone后code .→F5一步到位。而 VS 2019 在同样环境下光是安装 Python 工作负载就要 20 分钟创建项目要 5 分钟配置调试要 10 分钟且配置无法复用。4.2 单元测试集成让测试成为开发的自然延伸VS 2019 对 Python 测试的支持停留在“能跑就行”的层面。它能识别test_*.py文件但它的测试资源管理器Test Explorer对pytest的支持极差无法识别pytest.mark.parametrize的参数化测试无法显示pytest的详细错误堆栈只显示AssertionError不显示具体哪行assert失败更无法生成覆盖率报告。我曾试图在 VS 2019 里运行pytest --covapp结果它报错Coverage module not found因为 VS 的 Python 环境没有安装coverage包而它的包管理器又不支持pip install coverage它只认conda。VS Code 的测试集成是深度的、声明式的。它通过settings.json的python.testing.pytestArgs配置把pytest的所有能力都暴露出来。我的.vscode/settings.json中有这一段{ python.testing.pytestEnabled: true, python.testing.pytestArgs: [ tests/, -v, --covapp, --cov-reportterm-missing, --cov-fail-under80 ], python.testing.cwd: ${workspaceFolder} }python.testing.pytestEnabled: true启用 pytest 框架pytestArgs传递给pytest的参数。-v是详细模式--covapp指定要测app模块--cov-reportterm-missing在终端显示缺失覆盖的行号--cov-fail-under80表示覆盖率低于 80% 就失败cwd指定工作目录为项目根目录确保pytest能正确找到app/模块。tests/test_app.py的内容import pytest from app import app pytest.fixture def client(): app.config[TESTING] True with app.test_client() as client: yield client def test_home(client): Test the home route returns hello message. rv client.get(/) assert rv.status_code 200 assert bHello from VS Code! in rv.data def test_health(client): Test the health check route. rv client.get(/health) assert rv.status_code 200 assert rv.get_json() {status: ok}现在VS Code 的侧边栏 Test 图标会自动扫描tests/目录列出所有测试用例。点击Run All Tests它会执行pytest tests/ -v --covapp ...并在终端输出---------- coverage: platform linux, python 3.9.16-final-0 ---------- Name Stmts Miss Cover Missing ----------------------------------------- app.py 12 0 100% ----------------------------------------- TOTAL 12 0 100%如果我删掉test_health函数覆盖率降到 83%它会显示FAIL Required
