2025年10月11日·2 分钟
拉斯穆斯·莱尔多夫与 PHP：从个人工具到网络支柱
拉斯穆斯·莱尔多夫与 PHP 的故事——一组用于个人网站的小脚本如何演变成被广泛使用的平台，以及为什么今天仍有大量网站依赖 PHP。
拉斯穆斯·莱尔多夫与 PHP 的故事——一组用于个人网站的小脚本如何演变成被广泛使用的平台，以及为什么今天仍有大量网站依赖 PHP。
PHP 并非从一开始就是宏大的平台或经过精心设计的语言。它起源于 Rasmus Lerdorf 想要解决一个具体问题：在不反复手工操作的情况下维护个人网站。
这个细节很重要，因为它解释了为什么 PHP 即便在今天仍然有那种“感觉”。
Lerdorf 是早期网络时代的开发者，那时页面大多是静态的，任何超出纯 HTML 的更新都很快变得繁琐。他需要简单的脚本来跟踪访问者、重用常见页面部分并生成动态内容。
换句话说：他需要的工具能让他更快地交付变更。
“个人工具”不是品牌，而是一种心态。早期的网页构建者常常编写小工具来自动化枯燥的部分：
PHP 的早期版本正是被这种务实、快速解决问题的方式塑造的。
一旦了解了 PHP 的根基，很多特性就更容易理解：将代码直接嵌入 HTML 的设计、面向常见网页任务的大量标准库、以及偏好便利而非学术纯粹的取向。
这些选择帮助 PHP 快速传播，但也带来了权衡，我们稍后会讨论。
本文将梳理 PHP 如何从 Lerdorf 的脚本成长为社区驱动的语言，为什么它与托管环境和 LAMP 栈如此契合，像 WordPress 这样的生态系统如何放大其影响，以及现代 PHP（7 与 8+）带来了哪些变化——以便你能基于现实而非怀旧或炒作来判断 PHP 的价值。
上世纪 90 年代中期的网络主要是静态 HTML。如果你想要任何动态功能——处理表单、显示计数器、为不同访问者定制页面——通常会选择 CGI 脚本，常用语言是 Perl。
这能做到，但体验并不流畅。
CGI 程序为每个请求启动独立进程。对于简单任务，这意味着很多环节：脚本文件需要注意权限、服务器配置复杂、并且心智模型不像“写网页”。你不是在 HTML 中插入少量逻辑，而是在构建一个以文本形式输出 HTML 的小程序。
对爱好者站点和小型企业而言，常见需求很重复且务实：
大多数人使用的是共享主机，有有限的 CPU、内存，并对服务器设置控制很少。安装自定义模块或长驻服务不现实。你能做的只是上传文件并运行简单脚本。
这些限制推动出一种工具，需满足：
这正是 PHP 试图填补的差距——静态页面与重量级脚本之间的空白。
Lerdorf 并非打算发明一门编程语言。他想要的是更普通的东西：让自己的网站更容易维护。
最早的 “PHP” 工作是他用来跟踪在线简历访问的几段小的 C 程序，以及一些处理基本站点任务的工具，避免了频繁手工编辑页面。
那时，要知道谁在访问你的网站并不简单。Lerdorf 的脚本帮助记录并汇总请求，使理解流量模式更容易。
他同时还构建了用于常见网站事务的辅助工具——简单的模板、少量动态输出和表单处理——让站点看起来“有生命”，而不需要成为完整的定制应用。
一旦拥有了请求跟踪、表单处理和页面组件重用的工具，这些功能就不再只适用于一个页面或布局。
关键时刻在于：这些功能足够通用，其他站点所有者也能想象将其复制到自己的项目中。
因为它起源于工具箱，其可用性强调实用：快速完成常见任务，不要过度设计，降低上手门槛。
这种“先实用，后打磨”的态度一开始就让 PHP 感觉亲民易用。
结论很简单：PHP 的起点不是学术或理论，而是以问题为驱动，旨在让真实的网站更少摩擦地运行起来。
PHP 并不是人们今天所理解的那种“语言”起步。第一个公开里程碑是 PHP/FI，意为 “Personal Home Page / Forms Interpreter（个人主页/表单解释器）”。
这个名字很有寓意：它并不想成为包罗万象的工具，而是帮助人们构建动态页面并处理表单，而无需为每个任务编写完整程序。
PHP/FI 把几个实用的想法捆绑在一起，使早期网页开发变得容易得多：
虽然不够完美，但它减少了人们为让页面工作而必须编写的胶水代码数量。
早期网站很快遇到一个瓶颈：一旦想要反馈表单、留言簿、注册或基本搜索，就必须接受用户输入并进行处理。
PHP/FI 将表单处理作为核心用例。你不再把表单当作高级功能，而是直接支持它——读取提交的值并生成响应页面变得更加容易。
这种聚焦正好符合日常站长的需求。
PHP/FI 最具影响力的想法之一是其模板风格：把 HTML 作为主文档，并穿插少量服务端逻辑。
<!-- HTML-first, with small dynamic pieces -->
<p>Hello, <?php echo $name; ?>!</p>
对设计师和爱好者来说，这感觉很自然：你可以编辑页面并添加“恰到好处”的动态行为，而不需要采纳完全不同的系统。
PHP/FI 并不追求优雅，也没想做到完美。人们采用它是因为它：
这些“关键特性”并不华丽，但正是早期网络所需。
Lerdorf 的早期 PHP 脚本用于解决个人问题：跟踪访问者、重用页面元素、避免重复劳动。
把这套小工具变成大多数人认知中的“PHP”，并不是一次重大重写的结果，而是许多开发者逐渐认同并贡献的过程。
PHP 一旦公开，用户就开始提交修复、小功能与想法。那个反馈环很重要：项目开始反映众多站长的需求，而不再是单个网站的工具箱。
文档变得更好、边缘问题被修补，语言也逐步形成了便于上手的约定。
一个重要的转折点是 PHP 3，对核心引擎进行了重写，并引入了“PHP: Hypertext Preprocessor”这个名称。这不仅仅是品牌的改变。
重写使语言更一致、更易扩展，从而让 PHP 能在不变成难以维护的散件堆的情况下成长。
更广泛的用户社区推动了与他们依赖工具的集成。各种扩展开始出现，将 PHP 与不同数据库和服务相连，不再受限于单一配置。
PHP 从“输出 HTML 的脚本工具”变成了构建数据驱动网站（留言簿、论坛、目录、早期电商）的实用方式。
关键变化在于：社区贡献不仅仅是添 feature，而是把 PHP 的角色从便利工具变成一个值得为真实项目投入的平台。
PHP 并非仅凭易上手就成为众多网站的默认选择。一个重要原因是其“引擎”得到了认真升级——这让 PHP 运行更快、更一致、更易扩展。
Zend（由 Andi Gutmans 和 Zeev Suraski 创建）引入了 Zend Engine，相当于在不更改外观的情况下替换了引擎。
开发者仍然能写熟悉的 PHP 代码，但运行时内部变得更有结构性。这使得：
PHP 4（基于 Zend Engine 1）出现在共享主机流行的时期。托管商可以广泛且廉价地提供 PHP，从而形成增长循环：支持 PHP 的主机越多，使用者就越多；使用者越多，主机就越愿意继续支持它。
就实际效果而言，PHP 4 是“到处可用、够用”的选择。这种普及度与语言特性同样重要。
PHP 5（Zend Engine 2）让团队能为更大的代码库编写更结构化的代码。其重点是更强的面向对象支持：更好的类处理、可见性规则改进，为更现代的架构模式奠定基础。
这不是让 PHP 变得学究气，而是为了便于组织项目、重用代码并维护大型应用。
随着 PHP 的普及，人们开始期望老代码能继续运行。托管公司、CMS 平台和代理机构依赖稳定性。
从此，PHP 的演进不仅是“添加特性”，也必须考虑“不破坏现有网络”。
PHP 并非因理论上最优而获胜。它获胜是因为它让构建有用网页变得立刻可见且容易实现。
对早期的开发者——通常是设计师、爱好者或小企业——PHP 把“想法到可运行成品”的时间缩短得比几乎任何替代方案都多。
使用 PHP，反馈循环几乎没有摩擦：上传文件，刷新页面，立刻看到结果。看似平凡，但它塑造了一代人的网页构建方式。
人们可以从一个动态页面（联系表单、留言簿、计数器）开始，逐步扩展。
早期网页项目很少有大的工程队伍，通常只有一两个开发者和一堆紧急需求。
PHP 符合这种现实：减少部署仪式感，使渐进式改动更容易交付。
PHP 伴随廉价共享主机的浪潮。许多提供商预装 PHP，因此无需特殊基础设施或昂贵服务器。
部署往往就是“拷贝文件”，这与人们发布 HTML 的方式一致。
随着采用量的增长，教程、代码片段、论坛和复制粘贴示例随处可见。
这种社区记忆让 PHP 即便面对复杂问题也显得易学可用。
PHP 的成功不仅因为语言易学，还因为它有一个“默认家”——LAMP 栈（Linux + Apache + MySQL + PHP）。多年间，这一组合成为运行动态网站的标准配方，特别是对小型企业和个人项目而言。
Linux 与 Apache 廉价且易得。PHP 与 Apache 的请求/响应模型天然匹配：访问一个 URL，Apache 把请求交给 PHP，PHP 动态生成 HTML。
这无需单独的应用服务器，保持了部署的简单与经济性。
MySQL 补齐了场景。PHP 的内置数据库扩展使得连接 MySQL、执行查询并在网页中渲染结果变得直接而自然。
这种紧密集成意味着大量基于数据库的网站可以使用相同熟悉的工具来构建。
一个重要的加速器是共享主机。许多主机账号预先配置好 PHP 与 MySQL——无需系统管理经验。
使用诸如 cPanel 的控制面板，用户可以创建 MySQL 数据库，通过 phpMyAdmin 管理表，使用 FTP 上传 PHP 文件并快速上线。
随后出现的一键安装器（常用于 WordPress、论坛和购物车）把“网站 = PHP 应用 + MySQL 数据库”这种做法标准化，使得数百万站点业主选择了 PHP。
该栈鼓励一种实用的工作流：编辑 .php 文件、刷新浏览器、调整 SQL、重复操作。
也塑造了熟悉的模式——模板与 include、表单处理、会话与 CRUD 页面——这些心智模型持续影响了很长时间的网页开发实践。
PHP 之所以无处不在，不仅在于语法本身，还在于围绕它形成了完整的、可安装的产品——这些工具以最少配置解决了真实的业务问题。
内容管理系统把 PHP 转变为一次性选择。像 WordPress、Drupal、Joomla 这样的平合把难点打包——后台、登录、权限、主题、插件——站点所有者无需写代码就能发布页面。
每个 CMS 都形成了自己的引力：设计师学会制作主题，代理机构建立可复用的产品，插件市场蓬勃发展。
当客户网站依赖某个生态时，PHP 在很多情况下就被“再次选择”，有时客户自己都不知道底层语言是什么。
在线商店与社区站点是早期网络的刚需，PHP 非常契合共享主机环境。
像 Magento（以及后来的 WordPress + WooCommerce）、论坛应用 phpBB 等软件为商品目录、购物车、账户与审核提供现成方案。
这些项目还把“安装应用、在浏览器配置、用模块扩展”的工作流常态化——正是这种开发模式让 PHP 得以繁荣。
并非所有 PHP 都面对公众。许多团队用它做内部仪表盘、管理工具以及连接支付、库存、CRM 或分析的简单 API。
这些系统不会出现在“这个站点用的是哪种 CMS？”的扫描结果中，但它们保持了 PHP 的日常使用量。
当大量网站运行于少数几个庞大产品之上（尤其是 WordPress）时，其底层语言自然继承了这种覆盖面。
PHP 的影响力很大程度上来自其上层生态，而不仅仅是语语言本身的优劣。
PHP 的成功一直与务实相连——而务实常常会留下粗糙边缘。
许多批评都有历史依据，但并非都反映现代 PHP 的实际使用情况。
一个常见抱怨是接口不一致：函数命名风格各异、参数顺序不同、旧的 API 与新的并存。
这并非想象——它是 PHP 快速增长、随网而变、并为数以百万计的站点保留旧接口的结果。
PHP 也支持多种编程风格。你既可以写“能用就行”的简单脚本，也可以写结构化的面向对象代码。
批评者称其为“混合范式”；支持者认为这是灵活性。缺点在于如果团队不制定标准，代码质量可能参差不齐。
“PHP 不安全”是过度简化的说法。大多数 PHP 的安全事故源自应用层错误：信任用户输入、用字符串拼接构建 SQL、错误配置文件上传、或忘记权限检查。
PHP 的历史默认配置并不总是引导初学者走向安全模式，而它的低门槛又让很多初学者把代码直接上线。
更准确的结论是：PHP 让构建 Web 应用变得容易，而 Web 应用如果没有基本的安全卫生措施就很容易出错。
PHP 承担着一项重大责任：不要破坏互联网。
这种向后兼容性让长期运行的应用得以存活多年，但也意味着遗留代码会长期存在——有时远远超过其最佳寿命。公司可能会花更多精力维护旧模式，而不是采用更好的方法。
合理的批评：不一致性、遗留 API 与参差不齐的代码库确实存在。
过时的批评：认为现代 PHP 项目必然像早期 2000 年代那样，或认为语言本身是主要的安全弱点。
实际上，差别通常在于团队的实践，而不是工具本身。
PHP 的名声常与多年以前写下的代码联系在一起：HTML 与逻辑混在一个文件、风格不一致、以及“在我的服务器上能跑”的部署习惯。
PHP 7 与 8+ 不只是新增特性——它们推动生态向更清晰、更快速、更可维护的方向演进。
PHP 7 通过重构关键内部（Zend 引擎更新）带来了显著的性能提升。
通俗地说：同样的应用在相同硬件上能处理更多请求，或者在相同流量下成本更低。
这对共享主机、繁忙的 WordPress 站点以及关注“页面加载时间＝流失率”的业务非常重要，也让 PHP 在面对新一代服务端选项时重新具有竞争力。
PHP 8 引入了让大型代码库更易理解的特性：
int|string），减少猜测并提升工具支持；现代 PHP 项目通常依赖 Composer 管理依赖。
团队不再手工拷贝库，而是在文件中声明依赖、安装可预测版本并使用自动加载器。这也是当代 PHP 感觉更加“职业化”的原因之一。
旧 PHP 往往是临时脚本；现代 PHP 更多指版本化依赖、使用框架、类型化代码、自动化测试以及在真实流量下表现良好的性能。
PHP 不是怀旧的选择——它仍然适合很多网页任务。
关键在于把它和你的约束条件匹配，而不是意识形态式的偏好。
PHP 在以下场景表现优秀：
如果你的项目能从“众多开发者已经熟悉”和“托管无处不在”中获益，PHP 能显著降低摩擦。
在以下情况下应考虑替代方案：
当从零开始构建产品并希望获得现代架构的默认更佳实践（类型化 API、明确的服务分离）时，也值得考虑其他栈。
在选择前问自己：
有一条古老但永恒的教训：能把想法变成可运行软件的工具往往胜出。
如果你在评估是否继续投资 PHP 或同时构建新服务（例如 React 前端 + Go API），快速原型能去掉很多猜测。像 Koder.ai 这样的平台面向“先行发布”的工作流：你可以在对话中描述应用，生成可运行的 Web 或后端项目（React + Go + PostgreSQL），快速迭代并在准备好后导出源代码。
欲查看更多实用指南，请浏览 /blog。如需比较部署或服务选项，/pricing 可帮助你估算成本。
Rasmus Lerdorf 编写了一组基于 C 的小工具来维护他个人的网站——记录访问者、重用页面片段并处理简单的动态输出。
因为目标是减少重复性的网页工作（而不是设计一个“完美”的语言），PHP 保持了以实用为先的特性：部署快速、容易嵌入 HTML，并内置了面向网页的常用工具。
在 1990 年代中期，大多数页面仍是静态 HTML。要实现动态功能（表单、计数器、按用户定制的内容），通常要借助 CGI 脚本，常用语言是 Perl。
那种方式可行，但对于日常站点更新而言很笨拙：你更像是在写一个输出 HTML 的小程序，而不是在 HTML 页面中插入少量服务端逻辑。
CGI 程序通常为每个请求启动独立进程，并且需要更多配置（权限、服务器设置），思维方式也不同。
PHP 让动态输出更接近“编辑网页”的感觉：写 HTML、插入小段服务端代码、上传、刷新即可看到效果。
PHP/FI 代表 “Personal Home Page / Forms Interpreter（个人主页/表单解释器）”。这是一个早期的公开版本，专注于生成动态页面和处理表单。
它的“杀手”想法是能把服务端代码直接嵌入页面，同时为常见网页任务（尤其是表单和基础数据库访问）提供内置便捷的工具。
它降低了非专业开发者的门槛：你可以把 HTML 作为主文档，在其中插入小段动态代码（比如输出用户名或循环渲染结果）。
这种方式很符合共享主机时代的工作流程——以增量方式构建，而不是一开始就采用完全不同的模板系统。
PHP 一公开，其他开发者就开始提交修复、添加小功能和集成。这种反馈循环非常关键：项目逐渐反映了许多网站管理员的需求，而不再是一个人的工具箱。
文档变好、边缘情况被修补，语言开始形成约定，使得上手更容易。
PHP 3 是一次重大重写，使得核心引擎更一致、更易扩展，并引入了“PHP: Hypertext Preprocessor”这一名称。
从实践上看，这标志着 PHP 从一堆零散脚本向更稳定、可扩展的平台转变。
Zend 引擎（由 Andi Gutmans 与 Zeev Suraski 推动）改进了 PHP 的运行时内部结构，带来了更好的性能和更清晰的扩展路径。
这项改进使得托管提供商能够更广泛、更经济地提供 PHP 服务，同时开发团队也能构建更大的代码库并获得更可预测的行为。
LAMP（Linux、Apache、MySQL、PHP）成为动态网站的默认组合，尤其是在共享主机时代。
PHP 很契合 Apache 的请求/响应模型，并且与 MySQL 的连接非常直接——这使得成千上万的网站选择了相同的技术栈和工作流。
现代 PHP（7 与 8+）带来了显著的性能提升和更易维护的语言特性，Composer 也让依赖管理标准化。
在评估是否使用 PHP 时，请关注这些问题：
如果要扩展现有的 PHP 系统，渐进式现代化通常比重写更划算。