xiaohack's Blog - 代码质量
type: channel
link: https://blog.xiaohack.org/tag/eebc399c/
items: SonarQube Server 2025.6.1.117629 - 代码质量、安全与静态分析工具
items: 公司开始全面 vibe coding 之后感觉更累了
items: “全栈模式”必然导致“质量雪崩”！和个人水平关系不大~
items: AI Coding与单元测试的协同进化：从验证到驱动
items: 你是一个严格的技术经理，请用一个词评价一下当前的代码库，并给出理由。
items: Facebook 调查显示：越来越多的人开始采用带类型的 Python，以提升代码质量和灵活性

SonarQube Server 2025.6.1.117629 - 代码质量、安全与静态分析工具
type: item
date: 2026-01-21T12:05:28+08:00
description: SonarQube Server 2025.6.1.117629 - 代码质量、安全与静态分析工具SonarQube Server 2025 Release 6 (macOS, Linux, Windows) - 代码质量、安全与静态分析工具Self-managed static analysis tool for continuous codebase inspection请访问原文链接：https://sysin.org/blog/sonarqube/ 查看最新版。原创作品，转载请保留出处。作者主页：sysin.orgSonarQube Server代码质量和安全性由您掌控之前称为 SonarQube，本地部署的用于持续代码库检查的静态分析工具保持 AI 生成的代码干净释放 AI 编码助手的强大功能，而无需承担不良、不安全代码的风险。SonarQube Server 是您的干净代码解决方案，可以部署在任何地方、本地或云环境中。受到 700 万开发者和 400,000 多个组织的使用和喜爱提高代码质量的代码质量工具您的代码是一项商业资产。通过 SonarQube Server 达到干净代码状态，实现代码的最高价值。SonarQube Server 功能：代码智能利用 SonarQube 的深度洞察，更全面地了解您的代码库。通过减少认知负荷来提高开发人员的生产力。与顶级 DevOps 平台集成轻松加入项目。与 GitHub Actions、GitLab CI/CD、Azure Pipelines、Bitbucket Pipelines 和 Jenkins 集成，以自动触发分析并显示您工作地点的代码运行状况。代码审查通过 SonarQube 的质量阈值，防止不符合策略的代码进入生产环境。消除人工编写和 AI 生成代码中的问题，从而降低后期修复成本。高性能和可操作性按照您的方式进行部署，无论是在本地、在云中、作为服务器、使用 Docker 或 Kubernetes。多线程、多个计算引擎和特定于语言的加载可提供最佳性能。顶级分析速度和准确性在几分钟而不是几小时内收到可操作的清洁代码指标 (sysin)。Clean as You Code 会在您工作时检查较小的代码片段，为您提供有关新代码质量的准确反馈。重要语言的关键安全规则在您的开发工作流程中，在正确的时间和正确的位置无缝地发现编码问题。受益于 6,000 多个规则以及行业领先的 Java、C#、PHP、Python 等污点分析。共享、统一的配置设置特定的编码标准，使您的团队在代码健康方面保持一致并实现您的代码质量目标。另外，“边编程边学习” 可将开发人员的技能提升到同样高的水平。用于 IDE 的 SonarQube添加 SonarQube for IDE 扩展并将其连接到 SonarQube 服务器，以便在编码时动态查找编码问题，并确保您的团队遵循单一受监管的编码标准。测量代码覆盖率查看测试执行的代码库的百分比，以获得有关代码运行状况的宝贵见解。引导您到覆盖率低的领域进行改进。Sonar 的人工智能AI 辅助编码，由 SONAR 改进新的 AI 代码保证Sonar AI 代码保证是一个强大且简化的流程，用于通过结构化和全面的分析来验证 AI 生成的代码。这确保了每一段新代码在投入生产之前都符合最高的质量和安全标准。AI CodeFix 简介Sonar AI CodeFix 是一项强大的功能 (sysin)，可为代码分析解决方案 SonarQube Server 和 SonarQube Cloud 发现的问题提供代码修复建议。只需单击一下，您就可以获得有关如何解决一系列问题的建议，从而简化问题解决流程。笔者提示：此类功能通常需要有效服务合同。安全漏洞检测增强的开发人员安全工具 | 安全与机密信息检测静态代码分析Sonar 的静态应用程序安全测试 (SAST) 引擎可检测代码中的安全漏洞，以便在构建和测试应用程序之前消除这些漏洞。使用 SAST 为复杂项目实现强大的应用程序安全性和合规性。机密信息检测SonarQube Server 包含一个强大的机密信息检测工具，这是用于检测和删除代码中机密信息的最全面的解决方案之一。与 SonarQube for IDE 一起使用，它可以防止机密信息泄露并成为严重的安全漏洞。安全标准合规性SonarQube Server 可帮助您遵守通用代码安全标准，例如 NIST SSDF。将 SonarQube Server 与 SonarQube for IDE 结合使用，可以自动检查项目代码是否存在安全漏洞，并提高整体代码质量。基于开源，满足所有需求的版本SonarQube Server 版本：Community Build免费开源，可提高开发效率和代码…

公司开始全面 vibe coding 之后感觉更累了
type: item
date: 2026-01-21T09:04:24+08:00
description: 最近 15 人小组实践 vibe coding 遇到了一系列问题。整的我们连续加班了 1 个月。项目背景：公司里的核心项目。涉及资金流企业级复杂架构，对系统的稳定性和高可用性要求极其严苛。这个项目是专门为大促（比如双 11 ）这种极端高并发流量设计的，里面充满复杂的业务逻辑，比如多层级的数据核对、消息补偿机制和各种应急预案。技术路线上使用公司自研框架上从 0 到 1 开发。而且压力大的是，它是个倒排期项目，上线时间给定死了，一秒都不能拖。准备阶段：这次开始前我们内部讨论了很久，决定采用 SDD （规范驱动开发） 模式，即由规范和文档驱动 AI 进行架构设计、系统开发以及单测和集测的编写。出于数据安全的考虑，团队申请了一个全新的项目仓库。明确要求 AI 不能读取公司既有的私有代码库，以规避潜在的合规风险。由于 AI 缺乏对公司内部定制或自研框架的了解，我们手动编写了大量示例代码和 Todo 供 AI 学习。团队预先定义了多个 Agent （智能体），并设计了详细的 Workflow （工作流），试图通过流程化来约束 AI 的发散行为。惊喜的开始：• 详尽且专业的架构文档：AI 产出的架构设计文档看起来非常完善，甚至比人类写的还要好得多。人类写文档时往往会基于“常识”而忽略一些细节或内部约定，但 AI 会写得非常详尽，不遗漏细节。• 惊人的开发速度： 在纯开发阶段，AI 展示了极高的效率。内部估算，如果是由人类工程师完成该项目的纯开发工作，大约需要 15 到 20 人日，而 AI 仅用了 3 天时间 就完成了所有的代码编写。• 高质量的代码注释与异常处理： 我们平时为了追求开发速度，有可能对注释和异常处理的相对简单，但 AI 编写的代码在注释质量和异常处理机制方面比人类工程师开发出来的要好很多。• 清晰的设计与逻辑分层：AI 在接收到相关知识后，能够定义出非常清晰的类图、方法、依赖关系和分层结构。它会先进行详细的设计，明确每个类的职责，初步看过去代码质量非常不错。• 代码初期的易读性：AI 初步生成的代码逻辑相对直接（偏“面条式”代码），没有过度使用复杂的架构模式或抽象，这使得人类在第一眼看过去时觉得逻辑非常清晰且好理解。不过这样的蜜月期，并没有维持多久，很快我们开始遇到各类问题，加班也多了起来。遇到的问题：1. 技术与代码质量问题• 逻辑伪造与“将错就错”：AI 在面对缺失的知识、错误的接口文档或注释时，会伪造逻辑或猜测（ Mock ）返回格式。遵循“垃圾进，垃圾出”（ GIGO ）原则，如果输入信息有误，AI 的产出必然也是错误的。• 错误传播与测试盲区： 如果 AI 基于错误的架构分析生成代码，它也会基于同样的错误逻辑设计测试用例，导致单测和集测无法发现逻辑漏洞。• 产生“屎山代码”： 虽然 AI 初步生成的代码看似整洁，但在经过人工点对点的调试修复问题后，代码会逐渐演变成难以维护的屎山代码,。• 缺乏企业内部知识： 由于数据安全限制，AI 无法读取既有的私有代码库，且对企业内部定制或自研的框架缺乏了解，导致其难以写出符合要求的代码。• 不符合开发规范：AI 编写的代码往往不符合团队内部的开发规范或习惯（如事务处理方式），导致人类工程师在 CR （代码评审）或维护时感到非常困难。2. 架构与设计层面的局限• 输出不稳定与概率推断： 基于 Transformer 架构的 AI 本质上是概率推断模型，同样的输入和提示词产生的输出是不稳定的。我们为了研究针对本项目最佳的 AI 沟通方式，不断的测试修改各种提示词，花费了不少时间。• 上下文限制与“遗忘”：AI 的上下文处理能力有限，在解决具体问题时可能会忘记之前的全局设计，导致代码复用性差，甚至在同一项目中针对相同问题重复编写不同的代码。• “只见树木不见森林”：AI 容易陷入局部逻辑，忽略全局影响，例如在修改代码逻辑后忘记更新注释或相关的单元测试。• 文档过度冗长：AI 喜欢编写极其详尽、甚至带有重复内容的长文档，这增加了人类阅读和理解的成本,往往 AI 5 分钟输出的内容，我们要花 1 个小时去理解。3. 工作流程与效率悖论• 工作强度反而增加： 使用 AI 后，程序员的工作时长变得更长、更累，甚至需要工作到凌晨，这与“AI 减负”的初衷相悖。• 由于过度约束导致的“犯傻”： 为了约束 AI ，开发人员会定义越来越多的 Agent 和复杂的 Workflow ，但约束过多会导致 AI 出现“过敏”或变得笨拙，丧失了发散性思维的能力。• Token 消耗巨大： 复杂的 Workflow 和长指令会导致 Token 消耗量激增（每天消耗上亿 Token ），导致成本异常昂贵。• 陷入“面多加水”的死循环： 当 AI 做不好时，人类倾向于增加更多 Agent 或约束，这使得系统越来越…

“全栈模式”必然导致“质量雪崩”！和个人水平关系不大~
type: item
date: 2026-01-20T17:43:24+08:00
description: 在经济下行的大背景下，越来越多的中小型企业开始放弃“前后端分离”的人员配置，开始采用“全栈式开发”的模式来进行研发费用的节省。这方法真那么好吗？作为一名从“全栈开发”自我阉割成“前端开发”的逆行研发，我有很多话想说。先从一个活生生的真实案例开始吧。我认识一个非常优秀的全栈开发，因为名字最后一个字是阳，所以被大家称为“阳神”。“阳神”的“神狗二相性”阳神当然是牛逼的。他不仅精通后端开发，更是对前端了解的非常深。这样来说吧:当他作为后端开发时，他可以是那群后端同事里库表设计最清晰，代码最规范，效率最高的后端。当他作为前端开发时，他除了比几位高级别前端稍逊一点外，效率和UI还原性都非常高，还会主动封装组件减少耦合。但是非常奇怪的事情总是会发生，因为一旦阳神不是全职的“后端”或者“前端”时，一旦让他同时操刀“后端+前端”开发任务，作为一名“全栈”来进行业务推进时，他的表现会让人感到惊讶：他会写出设计糟糕，不规范，职责混乱的代码。这个现象我把他戏称为“阳神”的“神狗二相性”，作为单一职责时他是“阳神”，同时兼任多职时，他就有非常大的可能降格为“阳狗”。为什么呢？这是阳神主观上让自己写更糟糕的代码吗？不是的兄弟，不是的。这是系统性的崩塌，几乎不以人的意志为转移。换我去也是一样，换你去也是一样。分工粗化必然导致技术细节的差异从前，在软件开发的古老行会里，一个学徒需要花很多年才能出师，专门做一把椅子，或者专门雕一朵花。现在，你被要求从伐木到抛光，从结构力学到表面美学，全部一手包办。生产力在发展，对人的技能要求也在发展。因此“分工细化”成为了工业革命之后完全不可逆的趋势。在 IT 产业上也是如此。“软件开发”经过多年被细化出了前端开发、后端开发、客户端开发、大数据开发 等等多种不同的细分职业。但是现在有人想通过 粗化 职业分功来达到 “提效” 的目的，在我眼中这就是和客观规律对着干。人的精力是守恒的。当你需要同时关心useEffect的依赖数组会不会导致无限渲染，和kubectl的配置能不能正确拉起Pod时，你的注意力就被稀释了。你不再有那种“针对一个领域，往深里钻，钻到冒油”的奢侈。当你脑袋里冒出了一个关于前端工程化优化的问题时，身为全栈的你会本能地冒出另一个念头：在整个全栈体系内，前端工程化优化是多么边角料且无关痛痒的问题啊，我去深入研究和解决它的性价比实在太低了，算了不想了。如此一来，无论是后端的性能问题还是前端的性能问题都会变得无关紧要。结果是，只有业务问题是全栈开发要关心的问题。“岗位对立”与“自我妥协”在日常开发中，前端开发和后端开发之间互相吐槽争论是再正常不过的话题，而且争论的核心非常简单易懂：前端：这事儿不能在后端做吗？后端：这事儿前端不能做吗？可以的，兄弟，最后你会发现都是可以的，代码里大部分的事情无论是在浏览器端完成还是在服务器里完成都是可行的。但是，总有一个“哪方更适合做”吧？一个大屏页面的几万几十万条的数据统计，是应该后端做还是前端做？ 业务数据到Echarts展示数据的格式转换应该后端做还是前端做？ 用户数据权限的过滤应该后端做还是前端做？ 一个列表到底要做真分页还是假分页？ 列表已经返回了全量实体信息，为什么还要再增加一个详情接口？ 这都是日常开发时前端和后端都会去争论思考的问题，身处不同的职位，就会引入不同的立场和思考。前端需要去思考页面刷新后状态的留存，js单线程下大量数据处理的卡顿，页面dom树爆表的困境。 后端也需要思考并发下服务器资源和内存的分配，可能的死锁问题，以及用户的无状态token如何处理等。 前后端的“争吵”和观点输出是不可避免的。真理总是越辩越清晰的，后续讨论出的结果多半是最有利于当前现状的。但如果“前后端”都是同一个人呢？全栈模式，完美地消灭了这种“有益的摩擦”。当你自己和自己联调时，你不会给自己提挑战灵魂的问题。你不会问：“这个API设计是否RESTful？”因为你赶时间。你也不会纠结：“这个组件的可访问性够好吗？”因为你还得去部署服务器。这两种思想在你的大脑里打架，最终往往不是最优解胜出，而是最省事的那个方案活了下来。于是，你的代码里充满了“差不多就行”的妥协。这种妥协，一两个无所谓，当成百上千个“差不多”堆积起来时，质量的基础就酥了。内部摩擦的消失，使得代码在诞生之初就缺少了一道质量校验的工序。它顺滑地流向生产环境，然后，在某个深夜，轰然引爆。插播机-会技术大厂，前端-后端-测试，全国均有机-会，感兴趣可以试试。待遇和稳定性都还不错~工程的“不可能三角”软件开发领域有一个著名的“不可能三角”：快、好、省，你只能选两样。全栈模式，在管理者眼中，完美地实现了“省”（一个人干两个人的活）和“快”（省去沟通成本）。那么，被牺牲掉的是谁？雪崩时，没有一片雪花是无辜的。但更重要的是，当结构性雪崩发生…

AI Coding与单元测试的协同进化：从验证到驱动
type: item
date: 2026-01-19T21:55:46+08:00
description: AI生成代码质量难以把控！本文分享来自美团的技术实践，三大策略破解AI编程痛点。单测快速验证逻辑正确性，安全网保护存量代码演进，TDD模式精准传递需求。告别「看起来没问题」的错觉，构建AI时代的代码质量保障体系。一、引言目前，国内外很多AI Coding助手能在几秒钟内生成完整代码块，大大提升了开发效率，但这种高速开发模式也带来了潜在风险——与人工编码不同是，AI Coding助手生成代码存在两个特殊风险：其一，AI Coding助手依赖于上下文与模型自身的能力，输出的代码质量相对不可控。其二，AI生成的代码虽然逻辑通顺、结构完整，但可能隐藏着难以察觉的边界问题或逻辑缺陷。核心问题：我们如何快速的验证AI生成代码的质量和可靠性？本文旨在分享如何借助单元测试，让AI编程合作更高效可靠，主要解决三个常见痛点：肉眼审查困境：AI一次性生成大量代码时，难以快速准确判断逻辑完备性；存量代码信任危机：如何验证AI修改老代码时，不会产生非预期的结果；需求传达难题：如何精准向AI表达复杂需求并快速验证。针对上述三个常见痛点，本文提出采用不同的单元测试策略来应对以上问题。每个策略都针对一个特定痛点设计：策略一通过测试解决肉眼审查的局限性；策略二构建单测安全网应对存量代码的信任问题；策略三则采用TDD模式优化需求传达与验证流程。下文将依次展开说明，希望能对大家有所帮助或启发。二、策略一：单测检验AI代码逻辑正确性2.1 问题背景传统的人工代码审查在AI生成的大量代码面前显得低效且不可靠。在软件测试实践中，有着测试左移（Shift Left Testing）的概念，本质上是借助工具和测试手段更早地发现问题和预防问题。在AI Coding时代，这一理念尤为关键：跳过单元测试直接集成测试看似”抄近路”，实则是将风险后置——开发阶段几分钟能发现的Bug，在集成测试环境可能需要较长定位修复，这中间包含了代码部署、环境准备、测试条件的准备、问题定位、开发人员修复、再次部署验证等一系列漫长的环节。相比之下，单元测试具有独特的优势：它能够独立运行、快速验证结果，并且可以无限次重复执行。这种测试方式就像是为项目进行的一次性投资，却能为整个开发周期构建起一张可靠的“安全网”。它不仅能实时验证AI Coding生成的代码是否正确，更能持续保障未来代码的质量稳定性，让开发团队始终对代码库保持信心。2.2 案例：分页查询接口的隐蔽Bug任务背景：实现一个支持多条件筛选的复杂分页查询接口pageQueryRobotAI生成了如下核心查询逻辑：public List<AgentRobotE> pageQueryRobotsByCondition(List<Long> shopIds, String chatSceneCode, Boolean enabled, Integer pageNo, Integer pageSize) { // ... 前置校验代码 ... // 分页查询机器人基础信息 int offset = (pageNo - 1) * pageSize; List<AgentRobotEntity> entities = robotIds.stream() .skip(offset) .limit(pageSize) .map(robotId -> agentRobotDAO.getRobotById(robotId, false)) .filter(Objects::nonNull) // 问题代码：类型不匹配的隐蔽Bug .filter(entity -> enabled == null || Objects.equals(entity.getEnabled(), enabled ? 1 : 0)) .filter(entity -> Objects.equals(entity.getChatSceneCode(), chatSceneCode)) .collect(Collectors.toList()); return entities.stream() .map(this::convertToModel) .filter(Objects::nonNull) .collect(Collectors.toList()); } 问题分析：这段代码看起来逻辑完整，但第8行的过滤逻辑包含了多个复杂元素：三元运算符 enabled ? 1 : 0Objects.equals 的使用Boolean到Integer的隐式逻辑转换仅凭肉眼很难发现其中的类型不匹配问题。单元测试发现问题：通过AI编写了17个全面的单元测试用例，覆盖：正常场景：各种有效参数组合边界场景：null值、空集合处理参数组合：enabled为true/false/null的不同情况@Test pu…

AI Coding与单元测试的协同进化：从验证到驱动
type: item
date: 2026-01-18T12:45:56+08:00
description: AI生成代码质量难以把控！本文分享来自美团的技术实践，三大策略破解AI编程痛点。单测快速验证逻辑正确性，安全网保护存量代码演进，TDD模式精准传递需求。告别「看起来没问题」的错觉，构建AI时代的代码质量保障体系。一、引言目前，国内外很多AI Coding助手能在几秒钟内生成完整代码块，大大提升了开发效率，但这种高速开发模式也带来了潜在风险——与人工编码不同是，AI Coding助手生成代码存在两个特殊风险：其一，AI Coding助手依赖于上下文与模型自身的能力，输出的代码质量相对不可控。其二，AI生成的代码虽然逻辑通顺、结构完整，但可能隐藏着难以察觉的边界问题或逻辑缺陷。核心问题：我们如何快速的验证AI生成代码的质量和可靠性？本文旨在分享如何借助单元测试，让AI编程合作更高效可靠，主要解决三个常见痛点：肉眼审查困境：AI一次性生成大量代码时，难以快速准确判断逻辑完备性；存量代码信任危机：如何验证AI修改老代码时，不会产生非预期的结果；需求传达难题：如何精准向AI表达复杂需求并快速验证。针对上述三个常见痛点，本文提出采用不同的单元测试策略来应对以上问题。每个策略都针对一个特定痛点设计：策略一通过测试解决肉眼审查的局限性；策略二构建单测安全网应对存量代码的信任问题；策略三则采用TDD模式优化需求传达与验证流程。下文将依次展开说明，希望能对大家有所帮助或启发。二、策略一：单测检验AI代码逻辑正确性2.1 问题背景传统的人工代码审查在AI生成的大量代码面前显得低效且不可靠。在软件测试实践中，有着测试左移（Shift Left Testing）的概念，本质上是借助工具和测试手段更早地发现问题和预防问题。在AI Coding时代，这一理念尤为关键：跳过单元测试直接集成测试看似”抄近路”，实则是将风险后置——开发阶段几分钟能发现的Bug，在集成测试环境可能需要较长定位修复，这中间包含了代码部署、环境准备、测试条件的准备、问题定位、开发人员修复、再次部署验证等一系列漫长的环节。相比之下，单元测试具有独特的优势：它能够独立运行、快速验证结果，并且可以无限次重复执行。这种测试方式就像是为项目进行的一次性投资，却能为整个开发周期构建起一张可靠的“安全网”。它不仅能实时验证AI Coding生成的代码是否正确，更能持续保障未来代码的质量稳定性，让开发团队始终对代码库保持信心。2.2 案例：分页查询接口的隐蔽Bug任务背景：实现一个支持多条件筛选的复杂分页查询接口pageQueryRobotAI生成了如下核心查询逻辑：public List<AgentRobotE> pageQueryRobotsByCondition(List<Long> shopIds, String chatSceneCode, Boolean enabled, Integer pageNo, Integer pageSize) { // ... 前置校验代码 ... // 分页查询机器人基础信息 int offset = (pageNo - 1) * pageSize; List<AgentRobotEntity> entities = robotIds.stream() .skip(offset) .limit(pageSize) .map(robotId -> agentRobotDAO.getRobotById(robotId, false)) .filter(Objects::nonNull) // 问题代码：类型不匹配的隐蔽Bug .filter(entity -> enabled == null || Objects.equals(entity.getEnabled(), enabled ? 1 : 0)) .filter(entity -> Objects.equals(entity.getChatSceneCode(), chatSceneCode)) .collect(Collectors.toList()); return entities.stream() .map(this::convertToModel) .filter(Objects::nonNull) .collect(Collectors.toList()); } 问题分析：这段代码看起来逻辑完整，但第8行的过滤逻辑包含了多个复杂元素：三元运算符 enabled ? 1 : 0Objects.equals 的使用Boolean到Integer的隐式逻辑转换仅凭肉眼很难发现其中的类型不匹配问题。单元测试发现问题：通过AI编写了17个全面的单元测试用例，覆盖：正常场景：各种有效参数组合边界场景：null值、空集合处理参数组合：enabled为true/false/null的不同情况@Test pu…

你是一个严格的技术经理，请用一个词评价一下当前的代码库，并给出理由。
type: item
date: 2026-01-12T12:00:17+08:00
description: 看看你们的代码库是什么结果？我的：😆评价：脆弱理由：作为严格的技术经理，我最关注的是代码库的可持续性和变更安全性。尽管这个代码库有许多优点......

Facebook 调查显示：越来越多的人开始采用带类型的 Python，以提升代码质量和灵活性
type: item
date: 2026-01-09T22:10:21+08:00
description: Facebook 2025年Python类型调查在 1200 多名受访者中进行，重点介绍了 Python 开发人员如何以及为什么越来越多地采用该语言的类型提示系统。该调查还揭示了开发者最看重的东西，以及他们最大的挫折和愿望。 总体而言，86%的受访者表示他们“总是”或“经常”在代码中使用类型提示，其中具有 5-10 年 Python 经验的开发人员的采用率最高。 虽然数据显示，类型提示在被调查的样本中被广泛采用，但不排除选择偏差，因为使用类型提示的开发人员可能更有可能做出回应。尽管如此，该调查揭示了使用类型提示的 Python 开发人员的一些有趣趋势。 调查结果显示，Python 的类型提示系统已经成为大多数工程师开发的核心部分。[...]我们发现，所有经验水平的玩家对打字的接受程度都是相似的，但也存在一些有趣的细微差别。 初级（0-2 年经验）和高级（10 年以上经验）开发人员使用类型提示的频率都较低，分别为 83%和 80%。该调查的作者认为，初级开发人员面临更陡峭的学习曲线，而高级开发人员可能正在处理大型遗留代码库，而在这些代码库中采用类型提示更为困难。 开发人员列举了采用 Python 类型系统的几个好处，包括更好的可读性和代码内文档，改进的 IDE 和工具支持，早期的错误检测以及增强的信心。他们还强调了高级特性的价值，如协议、泛型和在运行时检查注释的能力。 另一方面，受访者指出了一些挑战，包括第三方库中有限的类型提示支持，泛型和修饰符等高级特性的复杂性，以及复杂类型的冗长性增加。其他痛点包括工具碎片化、缺乏运行时强制执行以及难以修改遗留代码。受访者还指出，Python 的类型系统似乎不如其他语言（如 TypeScript）的表达能力强，而且它的快速发展意味着语法和最佳实践在不断变化。 调查中另一组有趣的发现涉及改进 Python 类型系统的方法。一些建议包括借鉴 TypeScript 的特性，如交叉类型、映射和条件类型、实用程序类型（如Pick、Omit、keyof和typeof），以及更好的字典结构类型。其他建议侧重于更好地支持泛型和代数数据类型，包括更高级的类型；基于类型提示的可选运行时类型强制和性能优化；改进了对函数包装器和装饰器等模式的处理，支持动态属性；等等。 在工具方面，MyPy 仍然是首选的类型检查器，采用率为 58%，紧随其后的是 Pyright/Pylance。新的基于 Rust 的类型检查器（如 Pyrefly、Ty 和 Zuban）越来越受欢迎，被超过 20%的受访者使用。Visual Studio Code 是最常见的 IDE，其次是 PyCharm 和 Vim/Neovim。 这项调查中还有更多内容无法在此一一介绍。请务必阅读原始文章以获取全部详细信息。 https://www.infoq.com/news/2026/01/facebook-typed-python-survey/