企业官网建设流程全解析

你有没有遇到过这种情况：在PyCharm里打开一个普通脚本，激动地点下那个绿色运行箭头，结果控制台没有出现你的print输出，反而冒出一堆pytest的收集日志，什么test_session、test collected items，运行按钮上也挂着“Run 'pytest in xxx.py'”的字样。如果你现在的第一反应是“IDE是不是坏了”“是不是装错了解释器”，那我可以负责任地说：大概率都不是。真正的问题出在运行配置和测试文件识别规则上。这篇文章我会从现象判断开始，把“一运行就是test”的成因一层层拆开，然后给出修改回普通Python运行的具体步骤，最后再补几个我踩过很多次的边缘坑。

1. 先别急着右键删除配置，看懂“test运行”的真实表现

很多人在遇到这个问题时，第一反应是去网上搜“PyCharm怎么取消pytest”，然后一头扎进设置面板里改“Default test runner”。这个方向不能说完全错，但容易绕晕。因为“一运行就是test”这句话包含了好几种不同的现象，每一种对应的解决办法都不一样。先把现象看明白，再动手，比什么都重要。

1.1 三种最容易混淆的现象

第一种：右上角运行配置框里，当前配置显示为“test_xxx”或者“pytest in test_xxx.py”，点绿色箭头后控制台输出pytest的日志，比如Testing started at ...、Launching pytest、collected 2 items等等。这种是最典型的情况，说明PyCharm当前正在执行的配置就是一个“Python tests”类型的配置。

第二种：文件本身不是test开头，但右上角配置框却显示上一个测试配置的名字，比如你之前跑过test_login.py，现在打开了main.py，点运行按钮还是跑的test_login。这种情况和当前文件无关，纯粹是配置选择器保留了上一次的运行配置。

第三种：光标正好停在一个以test_开头的函数内部，右键运行时出现“Run 'pytest in ...'”，在主菜单里如果是“Run”也会指向pytest。这种情况其实是正常的，因为PyCharm按函数名识别出了你正在编辑一个测试函数。

我现在看到不少提问者发的截图，属于第一种和第二种的混合状态：文件是普通脚本，但配置框里挂着一个测试配置，所以一点运行就是test。这时候最简单的处理不是去卸载什么插件，而是先把配置框里的内容切换掉。

1.2 最简单的判断方法：看右上角的配置框

PyCharm右上角有一个下拉框，旁边是运行和调试按钮。这个下拉框显示的名字，比你手里的代码文件更值得关注。因为点击绿色箭头时，PyCharm执行的不是“当前打开的文件”，而是“当前选中的运行配置”。所以你先把这个下拉框展开，看看里面到底有几个配置，分别是“Python”类型还是“Python tests”类型。

如果下拉框里只有一个带pytest字样的配置，那问题就定位了：你之前运行过一个测试，这个测试配置被记住了，并且变成了默认选中项。如果下拉框里有多个配置，包括普通Python配置，那就手动切换一下就好。这种做法解决的是“配置被粘住”的问题，不涉及任何文件修改。

还有一种情况是从未运行过测试，但只要你新建一个test_xxx.py文件，右侧的运行图标自动变成pytest。这是PyCharm对测试文件的默认行为，属于命名规则触发的自动识别，需要从文件命名或运行配置层面去解决，后面会详细说。

2. 为什么PyCharm会默认跑你的test

要彻底解决这个问题，得先明白PyCharm判断“该运行什么”的依据。它并不聪明，本质上就是一套固定的优先级判断：当前选中的运行配置 > 当前文件的命名和作用域特征 > 项目里的测试相关配置。大部分“一运行就是test”都是这几个因素叠加出来的。

2.1 测试命名规则：第一块绊脚石

PyCharm对测试文件的识别，遵循一套非常传统的约定：文件名以test_开头、以_test结尾，或者类名继承unittest.TestCase，再或者函数名以test_开头。只要命中其中一条，编辑器就会把相关代码块当作测试对象，并提供对应的运行入口。

比如test_demo.py这个文件，哪怕你在里面写的是给业务系统发邮件的脚本，只要文件名里有test前缀，PyCharm在右键菜单里优先展示“Run 'pytest in test_demo.py'”。你点下去，它当然就启动pytest了。这就是很多人改了半天设置仍然无效的关键原因：你把默认测试运行器改成了unittest，但文件名没变，识别逻辑依然认为这是个测试文件。

和这个最容易混淆的是函数名规则。如果你在一个普通脚本里写了个函数def test_connect():，当你把光标放进这个函数再运行，PyCharm也会把这个函数当成测试用例来收集。区别在于，这时的普通脚本文件右键菜单里通常还会保留普通Python运行的选项，不会完全被pytest抢走。

2.2 默认测试运行器设置：会添乱但不是根本原因

Settings > Tools > Python Integrated Tools > Testing > Default test runner，这个选项控制的是当你使用测试框架时，PyCharm默认用pytest、unittest还是其他框架去执行测试。很多人误以为把它从pytest改成unittest，普通脚本就不会跑pytest了，其实这是两码事。

默认测试运行器只影响测试配置的生成方式，它不会改变PyCharm对普通Python脚本的执行逻辑。也就是说，即使你把默认测试运行器改成了unittest，只要你当前选中的是一个已经存在的pytest配置，点运行依然会跑pytest。所以这个设置可以作为辅助手段，但不要指望靠它一劳永逸。

如果项目里有pytest.ini、pyproject.toml里的[tool.pytest.ini_options]、setup.cfg里的[tool:pytest]这些配置文件，PyCharm会优先认定你的项目使用pytest，并在创建测试配置时自动选择pytest框架。这种情况下，即使你改Default test runner，也可能被项目配置覆盖掉。

2.3 运行配置的记忆特性：测试配置被“粘住”了

PyCharm的运行配置分成持久配置和临时配置两种。你手动创建的配置会一直保留在配置列表里，而通过右键菜单点击“Run”，PyCharm通常会生成或更新一个临时配置，然后把它设成当前激活项。重点是：这个激活状态会被保存下来，直到你手动切换或删除。

所以只要你上次运行的是一个测试配置，下一次点绿色箭头，哪怕打开的已经是main.py，它仍然会执行那个测试配置。这种“粘住”的行为让很多人产生了“IDE坏掉了”的错觉，其实就是配置选择器在记住你上一次的行为。

理解了这一点，你就能明白为什么“删掉test配置再重新点运行”是最有效的办法。因为删掉之后，PyCharm没有旧的测试配置可以记住，当你用正确的方式重新运行普通脚本时，新配置就会覆盖掉之前的记忆。

3. 把运行方式改回普通Python执行的三种方案

下面进入正题。我按改动幅度从小到大，给你列三条路线。如果你只是临时被测试配置缠住了，用方案一就能解决；如果文件命名触发了自动识别，方案三更彻底；如果卡在特殊情况，方案二是万能兜底。

3.1 方案一：右键菜单里主动选一次“Run '脚本名'”

最简单的方法，是在目标文件上右键，在下拉菜单里找到类似“Run 'main.py'”或“Run 'demo_script'”的选项，点击运行。这里的关键是选择普通Python运行项，而不是旁边的“Run 'pytest in main.py'”。一旦你手动选择了普通运行，PyCharm会立刻生成一个普通的Python临时配置，并把右上角下拉框切换过去。之后你再点绿色箭头，就是在跑这个普通脚本了。

有的朋友说右键菜单里根本找不到“Run 'main.py'”，只有pytest选项。这种情况通常出现在文件名是test_前缀的时候，或者光标位置恰好落在某个test_开头的函数上。这时候不要硬找，直接跳到方案二。

如果你是第一次运行某个普通文件，右键菜单里大概率会有“Run '文件名'”选项，因为文件名没有触发测试识别。优先用这一招，成本最低，不用打开任何设置界面。

3.2 方案二：删除Python tests配置，手动新建一个Python配置

当右键菜单不提供普通运行入口时，就需要手动创建配置了。操作路径是：点击右上角运行配置下拉框，选择“Edit Configurations...”。打开窗口后，左边列表会按类型分组显示。你找到“Python tests”这个分组，选中里面所有不想要的测试配置，点左上角减号删除。

然后点左上角加号，选择“Python”。在右侧面板里，Name填一个容易识别的名字，比如“run_demo”；Script path通过文件选择器选中你要跑的.py文件；Python interpreter选择当前项目所在的虚拟环境解释器。做完之后点Apply保存，再把右上角下拉框切换到这个新建的配置，点运行就是普通Python执行了。

这个方案能解决几乎所有“一运行就是test”的问题，因为它的本质是绕开测试识别，手动指定了一个普通的Python运行入口。手动创建的配置是持久配置，不会被临时测试配置覆盖，下次打开项目依然有效。

要注意的是，如果Script path选中的文件本身是test_开头，PyCharm在编辑器里还是会显示pytest相关的运行图标，但这不影响你用这个普通配置运行它。你完全可以把同一个test_demo.py文件同时挂一个pytest配置和一个Python配置，想跑测试时选前者，想跑脚本时选后者，切换起来很自由。

3.3 方案三：对症下药，关掉测试识别开关（改命名）

如果你跑的根本就是一个正经的业务脚本，只是因为它恰好叫test_send_email.py，所以被PyCharm误认为测试文件，那我建议你直接改文件名，这是根治方案。把test_send_email.py改成send_email_script.py，然后重新打开文件，右键菜单就会出现普通的“Run 'send_email_script.py'”选项，不用再手工创建配置。

同理，如果你的文件没有叫test开头，但函数名用了test_xxx，而你希望这个函数能被普通脚本调用，那也建议把函数名改掉，比如改成check_xxx、send_xxx这类不以test开头的命名。毕竟这个函数本身的语义可能就不是测试用例，没必要为了蹭测试前缀去和IDE的自动识别较劲。

命名这件事是最容易被忽略的。很多人觉得“反正就是个脚本名字而已”，但在PyCharm的自动测试识别规则里，test_前缀是最高优先级的信号。改掉名字，等于切断了自动识别的触发条件，后面所有右键菜单、运行配置都会回到正常状态。

当然，我强调一下，如果你写的确实是单元测试文件，那保留test_开头是对的，这是Python社区的约定。你只需要在需要把它当普通脚本跑的时候，用方案二去新建一个Python配置，不要因为想让配置变简单就把测试文件改名，那样反而会破坏项目里的测试发现。

3.4 备用手段：先用命令行验证脚本本身没问题

还有一种临时绕过IDE的方式，就是在终端里直接执行python test_demo.py。这种方式能非常直观地验证“脚本本身能不能跑”，但它的缺点是每次都要敲命令，不能利用PyCharm的运行按钮和调试能力。所以它更适合作为排查手段，而不是日常操作。

如果你在终端里能正常输出，但在PyCharm里点运行却进入pytest，那说明脚本逻辑本身没有问题，问题确实出在IDE的运行配置和测试识别上。如果在终端里也报错，那就说明代码本身有bug，别再盯着PyCharm的设置看了，先去把代码修好再说。

4. 配置层面再挖深一层：pytest.ini与“默认test runner”的真相

很多人在执行完前面三种方法后，可能会遇到一个更隐蔽的情况：明明刚删除了测试配置，也手动建了Python配置，但下次右键某个文件时，pytest又回来了。这不是操作错，而是项目级别的测试配置在影响PyCharm的判断。

4.1 项目里的pytest配置文件让IDE自动切换到pytest

当项目的根目录下存在pytest.ini，或者pyproject.toml中配置了[pytest]相关段落时，PyCharm会主动识别并启用pytest框架支持。如果你是在一个共享项目里，同事很早就添加了这些配置文件，这个功能会默认开启，你基本上不需要手动做什么，IDE就会把所有test_开头的文件识别成pytest测试文件。

有个典型的场景：某开发者从仓库拉了一个项目，里面既有测试代码也有工具脚本，工具脚本里某个文件叫test_report.py，本意是“生成测试报告的脚本”，但项目里有pytest.ini，于是每次运行这个文件都会去执行pytest的测试收集。这个案例里的工具脚本确实经常带test前缀，但它并不是真正的测试用例。这种情况下，光在IDE里删配置是不够的，因为下次pytest配置还会被自动生成，最省事的办法就是像3.3说的那样，把文件名里的test字样去掉，同时顺手告诉负责人这个文件其实不是单测。

所以，如果你的项目里有pytest配置文件，你处理“一运行就是test”的时候，不要只改IDE设置，还要检查文件名是否无意中撞上了测试识别规则。

4.2 修改Default test runner并不会直接让普通脚本变回run

这个问题值得单独说一次。有人会在Settings里把Default test runner从pytest改成unittest，甚至改成doctest，然后兴奋地点运行按钮，发现还是跑pytest。原因我前面讲过，这个选项只决定“新的测试配置默认用哪个框架”，它不会把你手动创建的Python配置替换掉，也不会阻止已有的pytest配置继续执行。

正确理解是：Default test runner管的是测试，不是普通运行。普通Python脚本的运行方式由“Python”类型的配置决定。你想让脚本按普通脚本模式运行，应该关注的是配置类型是否选成了“Python”，而不是Default test runner选了什么。

如果你真的希望项目里少一些pytest干扰，可以把Default test runner改成你实际使用的框架。比如项目用unittest，那就改成unittest，这样新建测试配置时会更统一，但普通脚本运行配置依然不受影响。

4.3 新建Python配置时最容易被忽略的选项

方案二里我提过新建Python配置的完整步骤，但有几个细节值得补充。

第一个是Python interpreter。很多新手新建配置时，会选到全局解释器，或者选到系统自带的base环境，导致项目里安装的第三方包在运行时报ModuleNotFoundError。正确的做法是选择项目里使用的虚拟环境解释器，通常路径是项目目录/.venv/bin/python，或者通过解释器下拉框里的“Show All”找到虚拟环境。

第二个是Working directory。有些脚本会读写相对路径文件，如果工作目录设置错误，运行时会找不到文件。在新建Python配置时，最好把Working directory设置为项目根目录，或脚本所在的目录，和你在终端里手动执行时的当前目录保持一致。

第三个是配置名称。建议用有意义的名称，比如“run_send_report”。不要让它和测试配置重名，否则你会在下拉框里分不清谁是谁。我在实际项目里见过有人把普通配置也命名为test_report，结果又和测试配置混淆，最后自己都搞不清该点哪个。

5. 我的排查链路和几个边缘坑

最后这部分，我把自己平时碰到“一运行就是test”时用的排查顺序整理出来，并说几个容易误导人的边缘情况。看完之后，你下次再遇到同类问题，应该五分钟内就能定位。

5.1 一套从现象到处理的快速判断表

先看右上角配置框。如果当前选中的配置是“Python tests”分组里的，直接删除或切换；如果当前文件是test_开头，右键菜单没有普通运行，就用方案二手动创建Python配置；如果项目里有pytest.ini，同时文件名撞了test前缀，优先改文件名；如果只是光标停在test函数内触发的，那就把光标移出去再运行。把这四种情况对应好，基本不会走弯路。

判断时记得排除干扰。比如你在调试某个被调用的函数，点运行的是入口脚本，不是测试用例所在的模块，那pytest的出现就可能是配置粘住了，和函数命名没关系。

5.2 90%场景下最省事的操作顺序

我个人的操作顺序是：先把右上角下拉框展开，如果当前存在普通的Python配置，直接切换过去运行，这一步就能解决一半的问题；如果没有，就在目标文件上右键，找找有没有“Run '文件名'”选项，有就用它；如果右键没有普通运行，那就进“Edit Configurations”删除测试配置，再新建一个Python配置。做完这三步，绝大多数“一运行就是test”都被解决了。

只有一种情况需要提前做额外判断，就是项目里有pytest.ini或者文件名叫test_开头。这时我会直接检查文件名是否合理，如果它不是测试文件，就顺手把文件名改掉，然后重复上面的三步。如果它确实是测试文件，那就不改名字，而是保持两个配置并存，用下拉框切换。

这个顺序看起来很简单，但它是从“现象”到“配置”再到“命名”的递进过程。我不会一上来就翻设置，也不会盲目重装IDE，因为那样既浪费时间，也不解决问题。

5.3 三个“看似相关但会误导你”的坑

第一个坑：以为是虚拟环境坏了。有些人遇到一运行就报pytest相关错误，以为是环境乱了，开始重新Create虚拟环境、重装依赖，弄了半天发现还是pytest。这时候其实应该先看运行配置类型，虚拟环境不会决定“运行pytest还是python”，它只影响运行后能不能import到包。

第二个坑：改了文件名后，旧配置还在。你把test_demo.py改成了demo.py，但右上角下拉框里可能还残留着旧的“pytest in test_demo.py”配置，点运行还是可能跑旧配置。这时你去Edit Configurations里把旧的测试配置删掉，再运行新文件就行。

第三个坑：以为调试按钮会改变运行类型。实际上，点击调试按钮只是启动调试器，它运行的目标仍然是当前选中的配置类型。如果当前配置是pytest，调试会调试测试；如果当前配置是Python，调试才会调试普通脚本。所以别指望调试按钮能帮你绕开pytest，它只会让你卡得更久。

我自己的习惯是，凡是需要当脚本运行的临时文件，绝不用test_开头命名；如果确实需要在测试文件和普通脚本之间切换，就手动保留两个配置，一个Python tests，一个Python，用下拉框决定今天跑哪一个。这套规则帮我少踩了很多重复的坑。