如何看待当下的AI挖洞？AI挖洞有没有前途 这两年做渗透测试、漏洞挖掘的人，应该都有一个越来越明显的感觉：AI 真的开始进场了。以前我们说“AI 挖洞”，多少还有点像一个概念。让大模型帮你分析代码、看看请求、解释一个漏洞，这些事情早就能做。但真到了 2025、2026 年，情况已经开始不一样了。现在的 AI 不只是“帮你写 Payload”。它开始自己读代码、分析程序、调用工具、运行测试、验证漏洞，甚至尝试修改补丁。所以很多刚入行的人会开始问一个很现实的问题：以后还需要学渗透测试吗？ AI 都能自己挖漏洞了，人还有什么价值？我的看法是：AI 挖洞肯定有前途，而且这个方向已经不是“有没有前途”的问题了，而是它已经开始成为漏洞研究的一部分。但另一件事也是真的：现在就说“以后 AI 可以完全替代渗透测试人员”，还早。一、先别急着说“AI 要取代黑客”，现在它已经能干什么？先看几个比较实际的变化。DARPA 的 AI Cyber Challenge（AIxCC）本身就是一个很典型的例子。这个项目专门研究利用 AI 自动发现、分析和修复软件漏洞。在 2024 年的半决赛中，参赛系统发现了 22 个独特的人工植入漏洞，并修复了其中 15 个，同时还发现过 SQLite 中的真实世界漏洞。到 2025 年的最终竞赛，AI 系统已经被要求在更复杂的软件环境里同时完成漏洞发现和修复。这说明一个问题：AI 挖漏洞已经不是 PPT 里的概念了。Google 这边也在做类似的事情。Google DeepMind / Project Zero 的 Big Sleep 已经被用于漏洞发现，Google 在 2025 年公开表示，它曾发现包括 SQLite 在内的真实世界漏洞；到 2026 年，Google 又表示已经把基于 Gemini 的 agent harness 扩展到了更大范围的 Chrome 代码库。OpenAI 也已经推出了 Codex Security research preview，用 agent 去理解项目上下文、寻找复杂漏洞、验证结果，并尝试生成修复方案。所以现在再说：“AI 只能写写代码，根本不会真正挖漏洞。”这个判断已经站不住了。二、但是 AI 挖洞和我们理解的“挖洞”，其实不是一回事很多人第一次接触 AI 挖洞，会产生一个误解：给 AI 一个网站。 然后 AI 自己扫描。 找到漏洞。 自动验证。 最后提交报告。如果真能稳定做到这个程度，那确实非常吓人。但现实距离这个状态还有明显差距。因为真正的漏洞研究，往往不是：“这里有没有漏洞？”而是：“这个功能到底是怎么工作的？”这两个问题完全不一样。举个很简单的例子。一个普通的 IDOR，你可能一眼就能发现：代码语言：javascriptAI代码解释/user/profile?id=1001改成：代码语言：javascriptAI代码解释/user/profile?id=1002然后看返回结果。这属于比较典型的自动化任务。但如果开发人员做了三层权限判断：代码语言：javascriptAI代码解释前端权限 ↓ API 权限 ↓ 业务对象权限而真正的问题出现在第三层。这时候就不是简单改个 ID 能解决的。你需要理解：用户角色之间有什么区别；对象属于谁；服务端到底在哪一步做权限判断；哪些接口共享同一个业务对象；某个状态变化之后权限模型有没有发生变化。这时候真正值钱的其实不是“会不会发请求”。而是：你有没有能力建立业务模型。三、AI 现在最强的地方，其实不是“发现神洞”，而是“扩大搜索面积”这一点我觉得特别重要。很多人讨论 AI 挖洞，总喜欢拿“AI 能不能发现一个超级复杂 0day”来判断它有没有价值。其实这个角度有点偏。AI 最大的优势可能根本不是：一次挖出别人十年没发现的神级漏洞。而是：以前一个人只能看 10 万行代码，现在可以让几十个 agent 同时帮你分析。这才是真正恐怖的地方。人类的问题是什么？时间有限。精力有限。注意力有限。一个研究员一天可能认真分析几个模块。但是机器可以同时跑大量任务。比如：代码语言：javascriptAI代码解释代码审计 ↓ 自动定位高风险函数 ↓ 生成测试用例 ↓ 尝试构造输入 ↓ 运行程序 ↓ 观察异常 ↓ 再次调整输入 ↓ 验证漏洞这个过程如果全部交给人工，成本非常高。但 AI Agent 可以把大量重复劳动吃掉。所以以后非常可能出现一种情况：不是 AI 替代漏洞研究员，而是“一个漏洞研究员 + 一堆 AI Agent”。一个人带着十个、二十个甚至更多自动化研究任务同时跑。这才是我觉得比较现实的未来。四、AI 挖洞真正的问题，其实是“误报”这个问题很多宣传文章不会重点讲。因为“AI 一晚上发现 5000 个漏洞”听起来很夸张。但你真正把结果打开：代码语言：javascriptAI代码解释Finding 0001 Finding 0002 Finding 0003 Finding 0004 ...然后发现：其中一大堆根本没法利用。还有一些：重复漏洞。再有一些：只是理论风险，实际攻击链根本走不通。这就麻烦了。HackerOne 在 2026 年公开讨论过这个问题：随着 AI 能力增强，漏洞报告数量明显上升，但增加的报告并不全部具有同等价值，其中会包含重复、无法验证、缺乏足够技术深度的提交。其平台 2026 年 3 月的报告量达到 46,947 份，同比增长 76%，而确认可利用的比例大约仍在四分之一左右。所以：发现 1000 个结果，不等于发现 1000 个漏洞。真正重要的是：代码语言：javascriptAI代码解释发现 ↓ 验证 ↓ 利用 ↓ 判断影响 ↓ 去重 ↓ 形成完整漏洞链 ↓ 写出别人能复现的报告最后这几步，目前仍然非常依赖人的判断。五、还有一个 AI 不太容易处理的问题：业务逻辑这个可能是我最看好的一个方向。因为很多漏洞并不是代码层面那种特别标准的：代码语言：javascriptAI代码解释SQL Injection XSS RCE SSRF而是：业务设计本身有问题。例如：一个平台正常流程是：代码语言：javascriptAI代码解释注册账号 ↓ 购买商品 ↓ 支付 ↓ 生成订单 ↓ 获得权益结果你研究半天发现：代码语言：javascriptAI代码解释优惠券校验在 A 接口 订单价格校验在 B 接口 最终权益发放在 C 接口然后 A、B、C 三个接口分别看起来都没什么问题。但是组合起来：就出问题了。这种漏洞特别依赖研究员自己的理解。你需要站到业务设计者的角度去想：“如果我是开发，这三个接口为什么这样设计？”然后再反过来找：“有没有哪一个状态，可以被我人为制造出来？”这类东西，确实是 AI 很想攻克、但目前仍然比较困难的地方。六、所以以后还值得学 Web 漏洞吗？我觉得更应该学。只是学习方式要变。以前可能是：代码语言：javascriptAI代码解释学 HTTP ↓ 学 Web 漏洞 ↓ 学 Burp ↓ 学扫描器 ↓ 刷靶场 ↓ 找漏洞以后更合理的路线应该是：代码语言：javascriptAI代码解释理解 Web 原理 ↓ 理解漏洞原理 ↓ 学会人工验证 ↓ 学会代码审计 ↓ 学会使用 AI ↓ 学会编排 Agent ↓ 人工 + AI 联合研究也就是说：以后最危险的不是“不会 AI 的安全人员”。真正容易被淘汰的，反而可能是：只会机械执行固定流程的人。比如：代码语言：javascriptAI代码解释打开 Burp ↓ 扫目录 ↓ 跑扫描器 ↓ 复制结果 ↓ 提交报告这一整套工作，本身就特别适合自动化。AI 只是让这个自动化过程进一步升级。七、那“AI 挖洞”到底有没有前途？如果你问我的判断：有，而且会越来越重要。但我不建议把它理解成：“以后 AI 自己挖洞，人就不用学了。”我反而更倾向于认为，未来会出现一种新的漏洞研究模式：代码语言：javascriptAI代码解释人 │ ├── 定义目标 ├── 理解业务 ├── 提出假设 ├── 设计攻击思路 └── 判断最终影响 │ ▼ AI Agent │ ┌──────┼──────┐ ▼ ▼ ▼ 代码审计 测试 验证 │ │ │ └──────┼──────┘ ▼ 人工复核 ▼ 最终结论AI负责大量重复工作。人负责真正困难的判断。这个分工，我觉得反而非常合理。八、以后什么样的人更吃香？这个问题其实比“AI 有没有前途”更值得问。如果一个人现在只会：“这个参数可能存在 SQL 注入，我用一下工具。”那确实会越来越卷。但是如果你能够做到：“我理解这个系统的业务逻辑，我知道它的数据怎么流动，我可以根据异常行为提出假设，再让 AI 帮我快速验证。”那完全是另外一个层级。未来真正有价值的能力，我觉得会逐渐向这几个方向集中：第一，漏洞原理。不是背 Payload。而是知道为什么这个 Payload 能成功。第二，代码理解。至少要能够读懂常见的 Web 后端逻辑。第三，业务理解。尤其是支付、权限、订单、身份、云服务这些复杂系统。第四，AI 使用能力。不是简单问 ChatGPT：“帮我找一下这个漏洞。”而是能够让 AI 成为你的研究助手。第五，验证能力。AI 说有漏洞，不代表真的有。你得自己证明。这一点以后可能反而越来越重要。九、最后说一个可能不太好听的事实AI 对漏洞挖掘最大的改变，可能不是：“以后 AI 会不会挖洞。”而是：“漏洞的产能可能会突然提高很多。”过去一个研究员一天能分析多少东西，有比较明显的上限。以后这个上限可能会被 AI 大幅度提高。于是问题就会从：“谁能找到漏洞？”慢慢变成：“谁能在海量自动化结果里找到真正有价值的漏洞？”这其实又回到了人的能力。你看得懂代码吗？你理解业务吗？你能判断攻击链吗？你能区分一个普通低风险问题和一个真正有影响的漏洞吗？你能让 AI 按照你的思路去工作吗？这些东西，才可能是未来几年真正拉开差距的地方。写在最后所以对于现在还在学渗透测试、漏洞挖掘的人，我反而不建议因为 AI 出现就开始焦虑。真正应该警惕的是另一件事情：还在用几年前的方式学习。以前我们可能花大量时间记工具参数、背 Payload、刷重复靶场。以后这些东西依然有用，但它们的边际价值可能会越来越低。真正值钱的，是你脑子里那套：发现问题 → 提出假设 → 验证假设 → 建立攻击链 → 判断影响AI 可以帮你把前面的路跑得更快。但最后那个“为什么这个系统会出问题”，依然需要有人真正想明白。所以 AI 挖洞有没有前途？答案其实已经不是一个未来时。它已经开始发生了。现在真正值得考虑的问题应该变成：当 AI 开始参与漏洞研究以后，你想成为被 AI 替代的人，还是使用 AI 的那个人？这个选择，可能比“AI 会不会挖洞”本身重要得多。

AI-Infra-Guard-腾讯朱雀开源AI红队平台 近期，不管是公司这一方面还是个人那一块，都如同着了魔一般地去构建AI应用。在本地进行Ollama的部署来运行DeepSeek，运用ComfyUI来开展绘图工作，利用vLLM来作为推理服务，在Dify以及Coze上进行拖拖拽拽的操作来搭建工作流，MCP Server也承接了不少相关事务。我周边搞开发的朋友，十个当中有八个在做这些个事情。但很少有人问一句：你搭的这些东西，安全吗？今年2月份朱雀实验室发过一个预警，说很多人本地部署的Ollama、DeepSeek这些开源AI工具，都带着默认配置漏洞，公网一开攻击者直接就能拿服务器。问题是知道有问题又能怎么样？总不能自己对着CVE列表一个个去核对吧？腾讯朱雀实验室将他们自身所使用的AI红队平台予以开源，此平台被称作AI-Infra-Guard，简称为A.I.G。该项目还成功入选了Black Hat Europe 2025 Arsenal。GitHub：https://github.com/Tencent/AI-Infra-Guard直白来讲，这个玩意儿就是专门用来给AI系统做安全方面检查的。以前是用Nessus去扫描服务器的漏洞，用Nmap去扫描端口，而A.I.G扫描的是AI的基础设施。它可不是那种写几个正则来匹配CVE编号的简单脚本，它从底层的模型服务，到中间的Agent工作流，再到上层的MCP插件，一层一层地给你进行检测。腾讯安全平台部于2019年成立了朱雀实验室。朱雀实验室曾经协助NVIDIA、Google、微软等厂商以及OpenClaw、Hugging Face等开源社区发掘了相当多的高危漏洞。朱雀实验室在Black Hat、DEF CON等会议上发表过论文，并且还出版过《AI安全：技术与实践》这一本书籍。朱雀实验室并非是那种去蹭AI热度的草台性质的项目。在GitHub上面存在着四千多颗星。更新的情况还算是比较频繁的。到了2026年6月份的时候还在连续地发布版本。来瞧瞧用户的列表吧，腾讯它自己、DeepSeek、工行、招行、vivo、OPPO、B站，就连蜜雪冰城都在进行使用。目前A.I.G集成了五个主要功能，基本把AI系统能出问题的地方都覆盖了：AI 基础设施漏洞扫描属于基础的功能。它可以对 100多种 AI 组件的指纹进行识别，能够匹配 1900多个 已知的 CVE。像 vLLM、Ollama、llama.cpp 这类推理引擎，Gradio、LangChain、Streamlit 这类开发框架，ComfyUI、n8n、Dify、Coze 这类应用平台，还有 ClickHouse 这类组件都可以被它识别到。在使用的时候输入 IP 或者域名，它自己进行识别版本、匹配漏洞库，之后直接就告诉你哪个组件存在什么漏洞、严重程度是如何、该怎么进行修复。接下来对于MCP Server和Agent Skill进行安全扫描。MCP当下已经成为AI Agent生态的实际标准，但是同时也是新的攻击重点区域。A.I.G可以检测14大类MCP安全风险，其中包含指令劫持、记忆投毒，还有远程代码执行、权限提升、依赖投毒这类常见问题。无论是扫描源码还是扫描远程URL都可以，不需要运行服务就能够检测。存在一个多Agent自动化红队扫描框架。此框架是专门用于对Agent工作流的安全性进行测试的。Dify以及Coze上运行着的Agent都能够接入进来进行测试。它会自动去查找越权、数据泄露、工具滥用这类相关的问题。如同给你的Agent免费聘请了一个红队来进行检查一样。大模型有关于越狱评估的相关状况。它内部内置了好几组越狱测试数据集。它会运用各种各样的方式去尝试突破你的模型。它还能够支持多个模型来进行横向的对比，直接就可以告知你哪一个模型更加难以被越狱。要是你去运用OpenClaw生态系统，直接安装“aig-scanner”这一功能模块便能够一键进行扫描操作，而无需单独地去部署整个平台体系 。界面是现代化Web UI，支持中文。Docker一键部署，4G内存、10G磁盘就能跑：在左侧的菜单当中去点击相对应的功能，然后填入目标地址便能够开始进行扫描，进度将会实时地进行显示，最终会生成可视化的报告，在这个报告里面有漏洞的详细情况、风险的等级评定、修复的相关建议，并且还可以进行导出操作。部署方式有三种，最快的是用预构建Docker镜像：Git clone https://github.com/Tencent/AI-Infra-Guard.git cd AI-Infra-Guard Docker-compose -f Docker-compose.images.yml up -d懒人的话直接用一键脚本：curl https://raw.githubusercontent.com/Tencent/AI-Infra-Guard/refs/heads/main/docker.sh | bash对该文章进行如下较为随意且存在表述问题的改写：访问了网址为http://localhost:8088的网站。默认的账号和密码那就是admin以及admin。进入到里面之后，得要记住去修改密码。如果只是想快速扫单个目标，不用部署Web服务，直接下二进制文件命令行跑就行：# 单个目标 ./ai-infra-guard -target http://127.0.0.1:11434 # 扫多个 ./ai-infra-guard -target 192.168.1.100 -target example.com # 加AI分析，让混元大模型给你出修复建议 ./ai-infra-guard -target http://127.0.0.1:8000 -ai -token your-token做CI/CD集成的话，还有个 aig-skill-scan 的Python包，pip装完就能在流水线里跑Skill安全审计：pip install aig-skill-scan export LLM_API_KEY="your-api-key" aig-skill-scan --repo /path/to/skill -m deepseek-v4-flash -o result.json我为什么推荐这个项目？首先来讲讲靠谱这回事。腾讯朱雀实验室所搞的这个东西，在Black Hat上面登台讲过，而且是大厂都在使用的，可不是那种个人开发者随随便便弄来玩玩的项目。再就是真的很全面，从底层的CVE到上层的MCP风险，还有Agent安全以及越狱测试，把AI安全的主要方面全都涵盖进去，不用你东拼西凑好几个工具。更新的速度还很快，我看到6月份还在更新，刚刚又加了39个新的AI组件指纹、600多条CVE规则，这样的项目才敢用在生产环境当中。首先得是好用的。WebUI操作比较简单，点那么几下就可以进行扫描。界面是中文的，不用你去编写一大堆的配置文件。有完整的API，还能够当作Skill直接安装到Agent里面去，对于DevSecOps是挺友好的。它是遵循Apache 2.0协议开源的，商业方面使用也没有问题，还可以自己添加规则插件。当下人工智能安全的情形确实有些可笑。所有人都急切地将人工智能往生产环境中推进，全然没有人去关注安全这件事情。这如同在2000年初的时候大家疯狂地建设网站，没有人去管SQL注入、XSS这些问题是一样的情况。等到出现了被拖库、被挖矿、数据泄露这些状况才想着去进行补救，到那个时候就已经晚了。不要等到出现问题了才去采取行动。花上三分钟的时间来对A.I.G进行设置，对您所运行着的很多人工智能应用做一番检查，这并没有什么不妥的地方。注：禁止对未授权的目标进行渗透测试GitHub地址：https://github.com/Tencent/AI-Infra-Guard

十个 AI Agent 渗透测试工具推荐，最后一个最适合手工党 从事AI安全相关的工作已经有一段时间了。在这一段时间里，GitHub上面的AI渗透测试工具那可就跟爆发了似的一下子多了起来。今儿个就来跟大家讲讲当下比较热门的十个项目，给很多想要在这个方面尝试一下的朋友们当作参考。服务器推荐服务器推荐：

如何白嫖腾讯云、阿里云1.5亿token 本文主要介绍了

Python很慢？这十个方法让你的代码执行速度提升3倍！ 前言Python，作为一种动态类型的解释性语言，确实在执行速度上可能不如C这样的静态类型的编译语言。但是，通过一些技巧和策略，我们可以显著提升Python代码的性能。本文将探讨如何通过优化方法使Python代码运行得更快、更高效。我们将利用Python的timeit模块来精确测量代码的执行时间。注意：timeit模块在默认情况下会重复执行代码一百万次，以确保测量结果的准确性和稳定性def print_hi(name): print(f'Hi, {name}') if __name__ == '__main__': # 执行print_hi('PyCharm')方法 t = timeit.Timer(setup='from __main__ import print_hi', stmt='print_hi("PyCharm")') t.timeit()如何计算Python脚本的运行时间呢？在time模块中time.perf_counter()提供了一个高精度的计时器，适合测量短时间，例如import time # 记录程序开始时间 start_time = time.perf_counter() # 你的代码逻辑 # ... # 记录程序结束时间 end_time = time.perf_counter() # 计算程序运行时间 run_time = end_time - start_time print(f"程序运行时间：{run_time} 秒")介绍一、I/O密集型操作I/O密集型操作（Input/Output Intensive Operation）指的是那些在执行过程中，大部分时间都花在等待输入/输出操作完成的程序或任务。I/O操作包括从磁盘读取数据、写入数据到磁盘、网络通信等。这些操作通常涉及到硬件设备，因此它们的执行速度受到硬件性能和I/O带宽的限制。他们的特点有：\1. 等待时间：程序在执行I/O操作时，往往需要等待数据从外部设备传输到内存，或从内存传输到外部设备，这会导致程序的执行被阻塞。\2. CPU利用效率：由于I/O操作的等待时间，CPU在这段时间内可能处于空闲状态，导致CPU利用率不高。\3. 性能瓶颈：I/O操作的速度往往成为程序性能的瓶颈，尤其是在数据量大或传输速度慢的情况下。例如，使用I/O密集型操作print，运行一百万次import time import timeit def print_hi(name): print(f'Hi, {name}') return if __name__ == '__main__': start_time = time.perf_counter() # 执行print_hi('PyCharm')方法 t = timeit.Timer(setup='from __main__ import print_hi', stmt='print_hi("PyCharm")') t.timeit() end_time = time.perf_counter() run_time = end_time - start_time print(f"程序运行时间：{run_time} 秒")运行结果为3s而不使用i/o操作执行一个方法，即调用这个print_hi('xxxx')空方法，不使用print()，程序明显快了不少def print_hi(name): # print(f'Hi, {name}') return如果代码中必要的时候，例如文件读写，可以使用如下方法提高效率异步I/O：使用异步编程模式例如asyncio，允许程序在等待I/O操作完成时继续执行其他任务，从而提高CPU利用率。缓冲：使用缓冲区暂存数据，减少I/O操作的频率。并行处理：并行执行多个I/O操作，以提高整体的数据处理速度。优化数据结构：选择合适的数据结构，减少数据的读取和写入次数。二、使用生成器生成列表、字典在Python 2.7及其后续版本中，引入了对列表、字典和集合生成器的改进，这些改进让数据结构的构建过程更加简明和高效。1、传统方法def fun1(): list=[] for i in range(100): list.append(i) if __name__ == '__main__': start_time = time.perf_counter() t = timeit.Timer(setup='from __main__ import fun1', stmt='fun1()') t.timeit() end_time = time.perf_counter() run_time = end_time - start_time print(f"程序运行时间：{run_time} 秒") # 输出结果：程序运行时间：3.3872999000595883 秒2、使用生成器优化代码注：为了方便以下内容皆省略主函数main的代码部分def fun1(): list=[ i for i in range(100)] # 程序运行时间：2.1053185999626294 秒从上述的推导式程序中可以看出，除了理解更简洁、更容易阅读之外，它也更快。这使得此方法成为生成列表和循环的首选方法。三、避免字符串连接，使用join()join() 是一个字符串方法，在Python中用于将序列中的元素连接（或拼接）成一个字符串，通常使用特定的分隔符。他的优点通常为：\1. 效率高：join() 是连接字符串的高效方法，尤其是当处理大量字符串时，它通常比使用 + 操作符或 % 格式化更快，在连接大量字符串时，join() 方法通常比逐个连接更节省内存。\2. 简洁性：join() 使得代码更加简洁，避免了重复的字符串连接操作。\3. 灵活性：可以指定任何字符串作为分隔符，这为字符串拼接提供了极大的灵活性。\4. 广泛的用途：不仅可以用于字符串，还可以用于列表、元组等序列类型，只要元素可以被转换成字符串。举例：def fun1(): obj=['hellow','my','name','is','xiaoyu','!'] s="" for i in obj: s+=i # 程序运行时间：0.3610708999913186 秒使用 join() 来实现字符串拼接：def fun1(): obj=['hellow','my','name','is','xiaoyu','!'] "".join(obj) # 程序运行时间：0.18804279994219542 秒使用join()将函数的执行时间从0.36秒减少到0.18秒。四、使用Map代替循环在多数场景中，传统的for循环可以被更为高效的map()函数所替代。map()*是一个Python内置的*高阶函数，它能够将指定的函数应用于各种可迭代的数据结构，如列表、元组或字符串。使用map()的主要优势在于，它提供了一种更为简洁且高效的数据处理方式，避免了编写显式的循环代码。传统的循环方式：def fun1(): arr=["hello", "my", "name", "is", "xiaoyu", "!"] new = [] for i in arr: new.append(i) # 程序运行时间：0.31288250000216067 秒使用map()函数做相同的功能：def fun2(x): return x def fun1(): arr=["hello", "my", "name", "is", "xiaoyu", "!"] map(fun2,arr) # 程序运行时间：0.18387670000083745 秒对比之后，使用map()节省了将近一半的时间，大大提升了运行效率五、选择正确的数据结构选用恰当的数据结构对提升Python代码的执行效率至关重要。各类数据结构都针对特定操作进行了优化，合理选择能够加速数据的检索、添加和移除过程，进而增强程序的整体运行效能。例如，判断容器内的元素的时候，字典的查找效率高于列表，但是是在大量数据的情况下，少量数据恰恰相反# 使用少量数据进行测试 def fun1(): arr=["hello", "my", "name", "is", "xiaoyu", "!"] 'hello' in arr 'my' in arr # 程序运行时间：0.11527379998005927 秒 def fun1(): arr={"hello", "my", "name", "is", "xiaoyu", "!"} 'hello' in arr 'my' in arr # 程序运行时间：0.17057139997836202 秒 # 使用 numpy 进行随机生成100个整数 def fun1(): nums = {i for i in np.random.randint(100, size=100)} 1 in nums # 程序运行时间：14.48330469999928 秒 def fun1(): nums = {i for i in np.random.randint(100, size=100)} 1 in nums # 程序运行时间：13.411826699972153 秒看到了在少量数据的情况下list执行效率是要大于dict的，但是在大量数据的情况下，dict的效率大于list如果有频繁的新增、删除操作，新增、删除的元素数量又很多时，list的效率不高。此时，应该考虑使用collections.deque。collections.deque是双端队列，同时具备栈和队列的特性，能够在两端进行 O(1)复杂度的插入和删除操作。collections.deque的使用from collections import deque def fun1(): arr=deque()# 创建一个空的deque for i in range(1000000): arr.append(i) # 程序运行时间：0.05507110000002058 秒 def fun1(): arr=[] for i in range(1000000): arr.append(i) # 程序运行时间：0.06128990000001977 秒list的查找操作也非常耗时。当需要在list频繁查找某些元素，或频繁有序访问这些元素时，可以使用bisect维护list对象有序并在其中进行二分查找，提升查找的效率。六、避免不必要的函数调用在Python编程中，优化函数调用次数对于提升代码效率至关重要。过多的函数调用不仅增加了开销，还可能消耗额外的内存，从而拖慢程序的运行速度。为了提升性能，我们应尽量减少不必要的函数调用，并尝试将多个操作合并成一个，以此来减少执行时间和资源消耗。这样的优化策略有助于我们编写更高效、更快速的代码。七、避免不必要的import虽然Python的import语句相对较快，但每个import都会涉及到查找模块、执行模块代码（如果还没有被执行过）、并将模块对象放入到当前命名空间中。这些操作都需要一定的时间和内存。当你不必要地导入模块时，就会增加这些开销。八、避免使用全局变量import math size=10000 def fun1(): for i in range(size): for j in range(size): z = math.sqrt(i) + math.sqrt(j) # 程序运行时间：15.630933800013736 许多程序员刚开始会用 Python 语言写一些简单的脚本，当编写脚本时，通常习惯了直接将其写为全局变量，例如上面的代码。但是，由于全局变量和局部变量实现方式不同，定义在全局范围内的代码运行速度会比定义在函数中的慢不少。通过将脚本语句放入到函数中，通常可带来 15% - 30% 的速度提升。import math def fun1(): size = 10000 for i in range(size): for j in range(size): z = math.sqrt(i) + math.sqrt(j) # 程序运行时间：14.933845699997619 秒九、避免模块和函数属性访问import math # 不推荐写法 def fun2(size: int): result = [] for i in range(size): result.append(math.sqrt(i)) return result def fun1(): size = 10000 for _ in range(size): result = fun2(size) # 程序运行时间：10.154493000009097 秒每次使用.（属性访问操作符时）会触发特定的方法，如__getattribute__()和__getattr__()，这些方法会进行字典操作，因此会带来额外的时间开销。通过from import语句，可以消除属性访问。from math import sqrt # 推荐写法：用到哪个模块就导哪个模块 def fun2(size: int): result = [] for i in range(size): result.append(sqrt(i)) return result def fun1(): size = 10000 for _ in range(size): result = fun2(size) # 程序运行时间：8.960758000030182 秒十、减少内层for循环的计算import math def fun1(): size = 10000 sqrt = math.sqrt for x in range(size): for y in range(size): z = sqrt(x) + sqrt(y) # sqrt() 求非负实数的平方根 # 程序运行时间：14.267008299939334 秒在上面代码中sqrt(x)位于内测for循环，每次循环都会重新计算，增加不必要的时间开销import math def fun1(): size = 10000 sqrt = math.sqrt for x in range(size): sqrt_x=sqrt(x) # 在外层for循环进行计算 for y in range(size): z = sqrt_x + sqrt(y) # 程序运行时间：8.499037600005977 秒总结通过这些方法，我们可以有效地提高Python代码的性能，使其在处理复杂任务时更加快速和高效。记住，性能优化是一个持续的过程，需要根据具体情况不断调整和改进，python运行速度的优化方法不限于以上方法，还有很多，如有大佬路过，请多指教。