PHP 2025 现状报告
《2025 PHP现状报告》 深入剖析开发者如何使用、偏好及依赖PHP，展现这一经典网络语言如何通过新型框架、增强工具及AI辅助工作流持续实现现代化转型。
本报告呈现了2025开发者生态系统调查的核心发现。除数据分析外，您还将聆听JetBrains PHP开发者倡导者Brent Roose的深度解读，以及其他社区专家对当前PHP发展动因与生态走向的洞见。
若想了解一年前的生态图景，请查阅《2024 PHP现状报告》。
参与者概况
今年我们收集了1,720名以PHP为主编程语言的开发者反馈，其中日本、美国、俄罗斯、中国和法国的开发者占比最高。
88%的PHP开发者拥有三年以上经验，其中六至十年经验的开发者占比最高。
团队规模与工作环境
超过半数(56%)的PHP开发者在2-7人的小型团队工作，另有12%为独立开发者。
语言采用与使用
多数PHP开发者(58%)计划未来一年内不迁移至其他语言。对于有迁移意向者，Go和Python是最具吸引力的替代方案。
新入行开发者比例缓慢增长：4%的从业者使用PHP不足半年(较去年2%上升)，6%不足一年。但仍有近四分之三(72%)的开发者拥有超过四年的PHP使用经验，彰显出该生态系统的成熟度。
“需特别说明的是，这些数据并非反映开发者放弃PHP，而是表明他们正在采用PHP之外的语言。看到众多PHP开发者将其他语言纳入技能库令人欣喜。PHP在某些领域表现卓越，但某些问题更适合用Go或Rust等语言解决。跨越语言壁垒的协作能创造非凡成果。”
“看到更多新人加入PHP阵营令人欣喜。鉴于过去几年PHP持续获得积极反响，这一趋势并不意外，但数据佐证更具说服力。”
现代化趋势持续推进：PHP 8.x以89%的使用率占据主导地位，而PHP 7.x已降至33%。旧版(5.6及更早版本)虽未完全消失，但占比已降至8%。欲深入了解PHP版本使用情况，请参阅布伦特的博客文章。
“开源社区在推动PHP社群采用更安全高效的版本方面发挥着关键作用。最棒的是借助Rector这类工具，升级过程变得极其简单。我亲身验证过：每年升级绝对物超所值。”
PHP框架与内容管理系统
框架采用率未出现重大变化：Laravel以64%的使用率持续领跑，其次是WordPress(25%)和Symfony(23%)。CodeIgniter、Yii和CakePHP等其他框架虽份额较小但保持稳定。
“我们欣喜地看到Laravel采用率持续攀升，这得益于Laravel Cloud等创新产品以及Laravel Boost和MCP等AI集成方案。Laravel始终致力于提供全面现代的全栈解决方案，使PHP开发效率和可访问性达到前所未有的高度。”
“Symfony贡献者持续拓展类型注解的表达边界，形成良性循环：代码库、静态分析工具和IDE不断优化，从而提升开发体验和可验证性。所有利益相关方之间的非正式沟通渠道使这一进程更加顺畅高效。”
PHP开发环境
最常用IDE或编辑器
工具领域变化尤为显著：使用PhpStorm或搭载PHP插件的IntelliJ IDEA的开发者占比上升10个百分点至68%。Visual Studio Code占比降至23%，而Cursor(6%)等新晋工具也已进入市场。
编码工具满意度
我们同时调查了PHP开发者对其主力IDE的满意度。其中53%的PhpStorm用户给予最高评价，而VS Code用户中仅有26%给予最高评分。
不同框架的首选IDE或编辑器
PhpStorm在Symfony开发者中占据绝对主导地位(83%)，并在Laravel开发者中领先(62%)，而WordPress开发者的选择则更为分散，VS Code仍保持着37%的受欢迎度。
您是否知道所有 PhpStorm 用户现可免费使用 Laravel 支持？此博客文章 详述了全部内容。
调试与测试
在调试方面，多数开发者仍依赖 var_dump 式方法(59%)，但调试器(如Xdebug)的使用率已小幅上升至39%。
“Xdebug的使用率历年保持稳定，在多次调查中始终维持在30%-35%区间。虽然我仍会进行大量’dd’或’log’调试，但掌握调试器并能灵活运用时，确实能节省大量时间。这项技能需要持续练习而非一蹴而就——因此我制作了这段简短视频，帮助大家快速入门Xdebug。”
PHPUnit(50%)仍是主流标准，但Pest的使用率增长了4个百分点达到17%，显示出开发者正积极转向现代化的友好测试框架。
“看到越来越多开发者选择Pest作为首选测试框架，我感到无比欣喜——今年调查数据的增长充分印证了我们近期版本的卓越品质。
调查发布后我们已推出Pest 4版本，新增测试分片、脏话检测以及革命性的浏览器测试。在PHP领域实现完善的浏览器测试堪称颠覆性变革，预计明年采用率将进一步攀升！”
然而仍有32%的开发者完全不编写测试，凸显出测试文化中持续存在的缺口。
代码质量工具
2025年的绝对赢家是PHPStan，其使用率跃升至36%，较去年增长九个百分点。诸如PHP CS Fixer(30%)和PHP_CodeSniffer (22%)仍被广泛使用，而Rector (10%)持续稳步上升。不过仍有42%的受访者未定期使用任何代码质量工具，表明该领域仍有提升空间。
人工智能应用现状
人工智能已成主流：95%的开发者至少尝试过一种AI工具，80%定期使用AI助手或AI驱动的编辑器。
ChatGPT以49%的日活跃率领跑，但其份额自2024年起呈下降趋势。GitHub Copilot(29%)和JetBrains AI Assistant(20%)紧随其后，后者采用率较去年增长三倍。
“人工智能已成常态。令人欣喜的是整体AI应用持续增长，而ChatGPT使用率下降正推动更专业化工具的普及。未来我们将见证更多新工具涌现，那些能显著提升效率的工具必将稳居日常开发栈。”
展望未来，72%的受访者表示未来一年可能尝试AI编码助手，仅8%认为可能性较低。
与此同时，并非所有企业都准备好拥抱人工智能。11%的受访者表示其所在机构未来12个月内不太可能尝试AI编码助手。除数据隐私安全顾虑(44%)和知识产权问题(24%)外，许多企业还面临对这类工具认知不足的困境(22%)。
2025生态系统亮点
FrankenPHP
“今年PHP领域我个人最关注的亮点之一，是FrankenPHP成为PHP基金会支持的项目。我认为该项目极有可能成为PHP的事实标准运行时，这将具有重大意义。FrankenPHP内置大量性能优化方案，可为任何PHP应用提供开箱即用的性能提升，兼具跨系统移植性，并支持工作进程模式实现PHP异步请求处理——相较于PHP FPM，其应用加速效果可达三倍。”
对PHP生态的启示
2025年调查结果证实PHP仍是一个稳定、专业且持续进化的生态系统。其强大的开发者群体、Laravel与WordPress的持续主导地位、现代工具的广泛采用以及对AI驱动工作流的快速接纳，都表明PHP远非“过时技术”。
本文文字及图片出自 The State of PHP 2025
看来去年有相当一部分人离开PHPStorm转投VS Code等工具，但并未坚持使用，今年又回来了。
JetBrains办公室里肯定松了一口气。
他们今年把Laravel插件在phpstorm上免费了
难道没人爱Symfony吗？ 🙁
Symfony开发者在PhpStorm里用插件。
没错，但我记得那个是付费的
这是免费增值模式，付费功能并非开发必需，只是额外的质量检查。我只建议为支持开发者付费(你应该这么做)。
没错，我们用这个，但每年要花几美元。
这确实改变了事情的节奏。
每当需要协助同事处理任务时，看到他们连基础操作都手忙脚乱，或在索引文件里翻找代码，我就庆幸自己坚持使用PHPStorm——它让我效率飙升(除了偶尔在macOS上崩溃或卡死)。
我个人认为VS Code搭配Cursor和IntelliSense同样强大。
性能更优，对PHPDoc泛型支持更出色
虽然被踩了，但你说得对。尤其付费购买IntelePhense后更值得。
确实如此，它能提供重构、查找实现等功能。我实在找不到PHPStorm的任何功能是IntelePhense无法提供的
没错。对我而言，考虑到两者在代码导航上的实际差异微乎其微，关键在于性能。我喜欢为每个正在开发或参考的代码库同时打开多个IDE实例。VS Code能更流畅地实现这种操作。
我从未遇到过这种情况；同时打开3-5个项目，每个项目3-5万行代码。
你遇到崩溃是在什么情况下？
单个或多个项目。尤其在macOS全屏模式下频繁发生。还有很多时候解锁后会无响应
你遇到过光标消失的问题吗？我用Clion(基本相同)，最近更新后光标时不时“休假”
没有，界面元素看似响应但完全无法点击。光标闪烁处无法输入。调整窗口大小时，界面无法同步更新(要么内容被截断，要么出现大片灰色区域)
我遇到同样问题，新macOS更新后更严重(M2 Pro设备)
[已删除]
去年他们前景黯淡时，媒体报道是否也存在偏见？
若传言属实，拥有如此坚固的护城河想必令人心旷神怡
VSCode的IntelePhense插件有何问题？它对PHP的代码补全和重构功能相当出色。
真希望我能继续用phpstorm，现在被迫用cursor :/ 我倒不介意AI功能，只是希望IDE本身能更好。
转用VS Code就像转用Vim。当然，你可以通过插件、集成和各种“技巧”让它们协同工作。或者…直接买个IDE算了。
看来很多人终于意识到：VS Code不过是带GUI的Vim。
我认为当初是AI功能吸引用户，但后来发现它还不够强大，大家就回流了。
类似的用户流失可能再次发生，所以JetBrains加速AI功能开发是明智之举。
咦，我倒不知VS Code有AI集成。记得2023年内部讨论IDE时，有人力推VS Code因其免费且“可扩展”，而我坚持PHPStorm——开箱即用且集成完善。
所有AI产品本质上都是VS Code扩展或其分支版本。
弃用PHPStorm转投Emacs……PHPStorm太贵、臃肿又卡顿😢
JetBrains近来真是每况愈下。最近因DataGrip频繁卡死不得不弃用，技术支持团队毫无头绪，只会让我反复尝试各种随机操作，耗费数月沟通仍无解。
应用本身过于臃肿，他们该专注核心功能而非堆砌无用特性。
单个用户遭遇难以调试的问题，不能断言整个公司及其产品“一落千丈”。
听着，我很欣慰他们支持PHP社区，也曾想继续支持他们。显然我的经历未必适用于所有人。但他们不仅无意解决问题，甚至漠不关心，这种态度已说明一切。他们宁可取消我的订阅也不愿解决问题。我多次提供内存跟踪记录，自己也花了近一小时协助调试应用程序。
没错，单个案例不能说明普遍规律
这算轶事吗？
禁用所有插件。问题依旧？则是程序错误
问题消失？逐个启用插件直至找到导致崩溃的那个
Jetbrains插件？他们能解决
其他插件…请咨询开发者
禁用所有插件只是第一步。数月来反复与支持团队沟通，尝试各种解决方案，包括彻底重装等。
没错，这是个bug。而他们根本不愿解决。我别无选择，只能取消订阅另寻他法。
酷
JetBrains是俄罗斯公司(如今正试图掩盖这点)，其大部分利润直接用于支持战争机器。难道大家忘了几年前JetBrains后门事件？SolarWinds黑客攻击同样是俄罗斯直接策划的重大事件。
所以没错，我的设备上绝不安装JetBrains产品。
这是由俄罗斯人创立的捷克公司，现总部设在阿姆斯特丹。
战争爆发后，他们清算了在俄罗斯和白俄罗斯的所有业务。
这只是个空壳。JetBrains的客户并非俄罗斯人，几乎全是西方国家用户，所以他们才试图掩盖公司起源。
你的证据何在？
注意：我不需要 主观断言，需要 确凿证据。必须是我能自行验证的事实，而非“兄弟你信我”或“某人告诉我”之类的说辞。
最明显的“证据”就是他们为SolarWinds攻击植入的后门程序。
除此之外，证据可能隐藏得相当隐蔽。或许存在一些战前留存的书面记录，能直接指向某些俄罗斯政府高官。
归根结底这是个人选择：要么盲目信任他们，要么选择替代工具(如IDE等)确保资金不会流向莫斯科。
这是非常有力的证据。
你关注过俄罗斯政权的所作所为吗？他们会直接把你从窗户扔出去。所以你只能：a)真心支持政权，b)服从命令保命，c)飞出窗外。
凭什么认为JetBrains会选择第三种？
另外，你是漏看了还是故意忽略了最关键的证据(已安装的后门程序)？或者纯粹想挑事就无视？要么就是俄罗斯的托儿。
JetBrains不是俄罗斯政权。难道JetBrains会把人扔出窗外？
所以根本不存在？真棒。
至于你最重大的指控——注意这 仅 是你的指控：
这个“后门”并非JetBrains“添加”的，更不是他们“为”任何目的添加的。你指责他们被他人利用，这 某种程度上 说得通，但你不仅止于“指责”，更直接控诉他们参与其中。
你毫无证据却如此笃定自己正确。真是令人惊叹。
你有什么证据证明它不是人为添加的？幕后黑手是FSB，而Jetbrains就是关键证据。多项独立调查均得出结论：该后门极可能并非“意外”添加。
你对“证据”的运作机制似乎不太了解吧，小伙子？🤣
有原始资料支撑吗？没有？那就别再幻想了。你显然对此事着迷了。
我一直以为是乌克兰公司。但最近查证后发现完全没有相关记载。
不。它由俄罗斯人创立，战争爆发后他们“与俄罗斯划清界限”，因为JetBrains 95%的客户都在西方国家。
这些老板赚得盆满钵满，本质上是寡头(他们极力掩盖这点)，与普京核心圈有联系。SolarWinds后门事件就很明显，那是俄罗斯联邦安全局的行动。
哇，看来PHP在日本很流行？！一直知道它在中国很火，但没想到在日本也这么受欢迎。
在日本做大做强的事就容易多了。
阿尔法城 https://youtu.be/tl6u2NASUzU?si=YP2XAARFnKXbDoGS
https://youtu.be/NM60iVDu79Y?si=o2xzzeskKHSugJyu
看到白俄罗斯上榜让我很惊讶。白俄罗斯不算大国(900万人口)，而且许多开发者都逃离了该国。
现在我更爱日本了。不过他们丑陋的网站设计除外 😁
我宁愿选择日本网页设计，也不要我们西方这套玩意儿。看看Reddit就知道了，以前是个丑但实用的网站，现在成了又丑又没用的网站，不过我猜它看起来很“现代”吧。
等old.reddit.com关停那天，我就走人。
等等，他们要撤掉旧版？
虽未正式宣布，但终究会如此。
没错，我也是。这“现代”界面简直糟糕透顶。
这就像大多数针对特定地区/国家的网站一样，是为他们的受众服务的。
https://youtu.be/z6ep308goxQ
哦，日本排名第一
(至少在报告里是这样)
令人沮丧的是，只有30%的PHP开发者懂得调试，其余人宁愿用var_dump/echo来调试。
公平地说xdebug难辞其咎，它的文档至今读起来仍像有人把脑海里的东西直接倒在页面上。整个官网散发着“2005年就被弃养”的气息。
我从2005年就开始尝试安装它了！
最终成功运行时它彻底改变了游戏规则，但配置过程实在令人头疼。AI辅助在这方面帮了大忙，尤其是在迁移到Docker后。我们大量使用符号链接，这也让Xdebug的配置更复杂了些。虽然还没完全按理想方式解决这个场景，但现有方案也能凑合用。
Xdebug必须成为PHP或PHP基金会的核心组件，必须获得第一类公民地位，包括代码覆盖率功能。
至今仍未实现实在令人难以置信。
赞同
Derick是PHP核心团队成员，且受雇于PHP基金会全职工作。
没错，但他不会将所有权移交给PHP或PHP基金会。
若想推广XDebug，就该简化配置流程。我至今觉得它配置起来相当麻烦
Phpstorm集成确实不错，但你说得对，我也是反复试错才搞定配置…尤其用nvim时还得学习nvim的dap命令
能否分享你现有的nvim/dap配置方案？
这是我当前配置的直接复制粘贴。可忽略delve相关设置。此配置假设你的XDebug开放9003端口。路径映射仅在源代码路径不同时重要，例如我的Docker容器映射到/srv/api，而主机代码位于~/Development/project
你还需要dap UI插件https://github.com/rcarriga/nvim-dap-ui
“` return {
{
“mfussenegger/nvim-dap”,
dependencies = { “leoluz/nvim-dap-go” },
opts = function(_, opts)
local dap = require(“dap”)
dap.adapters.delve = {
type = “server”,
host = “127.0.0.1”,
port = 2345,
}
dap.adapters.php = {
type = “server”,
host = “127.0.0.1”,
port = 9003,
}
dap.configurations.php = {
{
type = “php”,
request = “launch”,
name = “监听XDebug (Docker)”,
port = 9003,
pathMappings = {
[“/srv/api”] = vim.fn.expand(“~/Development/your_php_project”),
},
log = true,
ignore = {
“**/vendor/**/*.php”,
},
},
}
return opts
end,
},
} “`
并非我们不懂调试，只是Symfony的VarDumper能以更少精力完成95%的需求。我们并非时刻使用原始的var_dump/echo。
即便Xdebug的配置变得简单，但频繁开关导致的性能问题仍是实际应用的巨大障碍。每次调试都需额外考虑开关操作，这种特性在其他主流语言的调试工具中并不常见。
https://github.com/xdebug/xdebug/pull/996中部分变更正逐步融入Xdebug，这将带来长远的巨大裨益！
这里有个技巧：如果你使用docker compose，可以启动两个独立的php服务，一个启用xdebug，另一个禁用。然后在前面添加负载均衡器，根据
XDEBUG_SESSIONcookie的存在情况将流量导向其中一个。你可以通过不同的Web服务器实现：HeaderRegexp()规则可用于此目的HeaderRegexp()规则可供使用这样，您就能将所有流量路由到未启用xdebug的优化PHP服务，但一旦通过辅助扩展启用调试功能，系统便会自动切换至启用xdebug的服务——无需重启，毫无麻烦。
自那时起，xdebug扩展在关闭状态下的开销已大幅降低。我不认为这些技巧现在还有价值。
我始终开启xdebug，因此认同你的观点。但我的代码库并非symfony(更轻量级)，且使用相对现代高效的笔记本电脑——这并非人人具备的条件。一旦掌握技巧应用方法，其实成本并不高。
反复写入dump并移动代码块的做法，我实在看不出比设置断点逐步调试更便捷。
以下是典型调试流程(假设你不会长期开启Xdebug，因其性能开销巨大)，可见dd命令更易于理解…
使用dd时：
使用Xdebug时：
多数情况下，我使用时不会移动任何dump/dd语句。调试时通常已明确需要查看代码中哪个位置的值，因此会将其放置在相应位置。
使用Xdebug时：添加断点 – 刷新页面。移除断点可选 (当前我设置了约20个断点)
唯一需要禁用它(通过停止监听而非禁用扩展)的情况是处理复杂Doctrine实体时，有时会导致段错误。
这正是问题所在——即使没有监听器，启用状态下也会严重影响性能。若未察觉影响尚可，但在某些应用中可能导致速度下降2倍，本地开发时尤为痛苦。
另一方案是采用测试驱动开发。借助PHPStorm内置的测试工具，每次运行测试时只需点击按钮即可决定是否启用Xdebug。采用这种模式，你无需在Web服务器层级持续启用Xdebug。这对我而言堪称变革性突破。
Xdebug堪称改变人生的利器。但同样重要的是，我倾向于在JavaScript中使用console.log而非调试器。
[已删除]
这大概就是集成开发环境的意义所在。我用了多年Sublime却始终无法实现Xdebug集成，直到切换到专业的IDE——PhpStorm才解决问题。之前真是错过了太多。
[删除内容]
卖给谁？绝大多数开发者都在用能配合xdebug的IDE。
[删除]
那你怎么确定独立调试器会热卖？你自己去查数据吧。
[删除]
考虑到可能只有你自己会购买，开发独立调试器是否值得投入时间尚存疑问。
该调查缺乏针对性，未能单独统计PHP开发者群体。
况且Sublime已支持运行xdebug。
我对此存疑，因为调试器与源代码的集成度实在太高。
[删除内容]
检查当前断点状态和内联运行代码——我经常这么做，后者尤其节省时间。综合这些因素，在完整IDE或至少文本编辑器中集成调试器是合理的。
这只能怪他们了。我实在无法想象要倒退回手动记录值的时代。调试器带来的效率提升堪称革命性，即便它并非完美无缺。
我至今仍在努力说服团队采用它。
他们总是一味滥用自定义的
dump and die;方法来追踪函数调用路径，简直令人抓狂。我2021年才入行开发，xdebug文档简直糟糕透顶。今年接触Go语言的delve后才开始用它——那简直是革命性的体验，文档也强太多。先在delve学了基础，再迁移到xdebug。
仍在学习中，但目前能在运行时观察初始化过程对我帮助极大，或许该看看别人如何使用它的教程
那该怎么调试？
32%的人不写测试 😬
咦？打印调试在资深开发者中普遍存在，适用于所有技术栈和领域(包括主流技术)。这种方法可移植性强，无需学习额外调试工具就能在任何技术栈中生效。所以它不会消失。
[已删除]
才不会呢。
考虑到我们拥有庞大的生态系统，但只有1720名开发者参与了这项调查，我怀疑其有效性🤔。
人们为何想要迁移到Go语言？
[已删除]
更优性能、简易并发、强大的标准库、相对易学、简洁的构建部署流程。
它能很好地解决PHP难以实现的诸多场景。
自己琢磨吧。
没错，我同时用两种语言写过很多代码，Go确实很牛
你最后两点相当主观。基础Go确实易学……但仅限于基础操作。一旦涉及并发和通道，就完全是另一回事了。Go还采用组合式编程模式，与OOP截然不同，需要适应期。指针也是个问题，毕竟多数开发者被弱类型语言宠坏了。
这话我听过，但不确定实际影响有多大。不过：我的编程之路是从汇编语言(没错，不是打字错误)起步，接着是C语言，然后是PHP。从汇编的寄存器切换到C的指针，简直是质的飞跃 😉
我理解并发对某些场景很重要。比如Symfony CLI用Go编写，就能启动多个工作进程并处理并行HTTP请求。
但仅此而已。项目规模稍大，Go的弊端就会显现。
这正是我对Go最大的诟病。隐式接口的设计简直糟糕透顶。它迫使用户将代码逻辑牢记于心，以避免意外的服务标签化(等效实现)。再如抽象类：我虽不常使用，但庆幸需要时能灵活调用。
更糟的是缺失异常机制。每段Go代码都充斥着这样的结构：
每10-20行代码就出现一次。
我认为结构化子类型化应作为语言默认机制，但显式命名类型也应得到支持。但若非二选一，结构子类型化带来的优势如此显著，我每次都会选择它。虽然会失去仅标记接口，但我始终认为这属于接口滥用(尽管我仍在使用，但仍视其为滥用)。
不过你关于10-20行的说法大错特错：实际更接近每5-10行。更糟的是Go强制要求所有类型支持“零值”，错误返回时必须返回该值。这不仅意味着每个指针都可能为空——重蹈价值十亿的错误覆辙——还意味着结构体无法强制执行任何有效性不变量，因为它们必须支持每个成员都可能为空值、零值、空数组等状态。
虽然Go语言写出了许多优秀软件，但我最近就遇到Traefik在找不到匹配证书时抛出空指针异常的情况。这类错误本可通过非空类型和真正的异常(或至少真正的结果类型)来避免。
炒作从何而来？这语言现在都算老古董了。
它出自谷歌之手。微软同期推出的TS也经历类似情况：当巨头推出新事物时，众人往往蜂拥而至。
TS是卓越的语言，但Go极其基础，因此能迅速吸引大量新手。若添加完整的面向对象和异常机制，它将迅速失去市场份额。
有人会说Facebook开发的Hack从未流行起来，这确实如此。我认为原因在于Facebook早已饱受诟病，它与PHP存在历史关联，后来Facebook又放弃了兼容层…它从一开始就没有机会。
没错。十五年前的事了。当时确实掀起过热潮，我记忆犹新。它曾被视为下一个颠覆者，直到最终未能实现。我并非说它消亡了，它确实在生态系统中占据了一席之地。
我认为微软推出TypeScript并未助其摆脱炒作困境。世界历经多年挣扎终于开始摆脱IE怪兽的桎梏，而考虑到微软“拥抱、扩展、消灭”的策略，许多人对依赖微软语言构建网站持高度怀疑态度。很多人似乎忘了，过去十年间微软为修复品牌形象、积累善意付出了多少努力。
我认为，TypeScript的成功并非源于炒作，而是因为它本身卓越的品质——尽管当时整个行业都对微软抱有偏见。作为一款优质产品，其实用性无可否认。早在涉足操作系统领域之前，微软就是一家开发工具公司，无论是打造Visual Studio Code还是创建Azure云平台，都使其处于更核心的位置，能够为TypeScript提供完善的支持、精良的设计和便捷的体验。加之JavaScript正处于爆发式增长期，TypeScript恰好乘势而上。
我确认这些数据与我们公司的情况吻合。
惊讶于无测试比例仍维持在30%左右，怀疑这是否与所用框架/CMS存在关联。
我是业余新手。为何有人坚持使用旧版PHP而不及时更新？
合理原因有很多。举个例子：你运营的自助终端机为客户提供服务，它运行着PHP5.6和Apache，但升级需同步升级操作系统。但若硬件老旧或特殊(比如需要特定外设驱动)，升级可能存在风险。因此自助终端供应商宁可全价出售全新硬件，也不愿提供复杂的升级方案。想必大家还记得公共屏幕上出现老式Windows蓝屏的场景吧？
PHP作为网络时代的先驱者，众多企业已长期使用至今。早期许多操作需手动完成，依赖项更新既繁琐又耗费成本——除非及时维护，否则多数企业会选择忽视，除非直接影响到他们的钱包。
这也是PHP领域存在大量外包工作的关键原因之一
我同时使用7.2、7.4和8.2版本处理不同项目。
选择7.2是因为存在遗留MongoDB系统，既无时间也无意愿升级——毕竟升级收益有限，且该系统依赖的通信库仅支持7.2及更早版本。该系统完全内部化，不对外公开，故影响甚微。
使用7.4是因为拥有数十个WP站点，若要逐个检查所有插件是否兼容PHP8…唉，只能拖延至万不得已时再处理。至少WP核心本身已适配8.2版本。
8.2仍是当前主流版本，因此未来一年内我无需为此找借口。
有位客户根本不允许我花时间做更新。既然没坏就没必要修。
与运行数十年的软件保持兼容性。企业根本不在乎开发者圈子如何吹捧“新潮炫酷”的编程语言及其版本。他们的优先级截然不同。语言引入的大多数新特性都闲置不用，因为企业根本不需要它们。因此开发者主要能通过安全性和性能角度来推广新版本语言。但如今性能提升对前端/后端用户体验或业务运营的影响微乎其微，往往不被察觉。而“安全性”优势也逐渐消失——由于市场对旧版PHP仍有大量需求，各类项目开始持续为旧版本打补丁。
企业缺乏升级版本的实际需求。虽然可强制升级，但他们极度抵触这种做法，转而投向那些不会强迫升级的企业级语言。这无疑是摧毁生态系统的重要途径。
[已删除]
肯定是WordPress团队干的
他们根本不在IDE里用这些工具。我虽然不用IDE里的花哨工具，但有个精简的Makefile帮我运行phpstan/phpunit/phpmd/phpcs
超过十年了吧…我记得是2001年。PHP 3配MySQL 3