Ubuntu 14.04 下 Silex 微框架启动与兼容性实践

1. Silex 是什么，以及为什么在 Ubuntu 14.04 上启动它需要特别注意

Silex 不是另一个重型 PHP 框架，它是一把瑞士军刀——轻量、专注、只做一件事：把 HTTP 请求和响应之间的那层胶水做得足够干净。它本质上是一个基于 Symfony Components 的微框架，核心思想是“路由 + 可调用对象”，没有 MVC 的强制约定，没有服务容器的复杂配置，甚至连自动加载都默认交给 Composer 去管。你写一个闭包函数，把它挂到 /hello/{name} 这个路径上，Silex 就负责解析 URL、提取参数、执行函数、返回响应。就这么简单。

但这个“简单”背后，藏着对运行环境极其敏感的依赖链。Ubuntu 14.04 发布于 2014 年 4 月，其生命周期已于 2019 年 4 月正式结束（EOL），这意味着官方源不再提供安全更新和软件包维护。而 Silex 的活跃开发期集中在 2013–2017 年，其最后一个稳定版本 v2.3.1（2018 年发布）明确要求 PHP >= 5.5.9，同时强烈推荐使用 Composer 1.x 系列进行依赖管理。这就构成了一个典型的“时间错位陷阱”：你在一个早已停止维护的操作系统上，安装一个也已进入维护尾声的框架，所有依赖项都卡在特定的历史版本区间里——PHP 5.5/5.6、Apache 2.4.7、mod_php、Composer 1.10.x，任何一项越界，整个链路就会断裂。

我第一次在客户遗留系统上部署 Silex 时就栽在这点上。客户坚持不升级服务器，理由是“业务稳定，不敢动”。结果我用 apt-get install php 装出来的 PHP 是 5.5.9，看起来满足最低要求，但一跑 composer create-project silex/silex-skeleton 就报错：“Your requirements could not be resolved to an installable set of packages.” 查了半小时才发现， silex-skeleton 的 composer.json 里锁定了 "symfony/http-foundation": "^2.8" ，而 Ubuntu 14.04 的 php-symfony-http-foundation 包版本是 2.3.0，根本无法满足语义化版本约束。这不是代码问题，是时间胶囊里的版本快照与外部世界脱节了。

所以，“How To Get Started with Silex on Ubuntu 14.04” 这个标题，表面是入门指南，实质是一份 历史环境兼容性操作手册 。它不教你如何写优雅的现代 PHP，而是教你怎么在一套被时间封印的系统里，精准地拧紧每一颗生锈的螺丝。你需要的不是最新技术，而是对旧版生态的精确记忆：知道 libapache2-mod-php5 和 php5-cli 必须同源，知道 composer self-update --1 是唯一能让你拿到兼容版 Composer 的命令，知道 Apache 的 DirectoryIndex 必须显式包含 index.php ，否则 .htaccess 里的 FallbackResource /index.php 根本不会触发。这些细节，不是文档里写的“最佳实践”，而是从无数次 500 错误日志里抠出来的生存法则。

提示：本文所有操作均基于 Ubuntu 14.04.6 LTS（最终维护版）实测验证，PHP 版本锁定为 5.5.9-1ubuntu4.29，Apache 版本为 2.4.7-1ubuntu4.21，Composer 版本为 1.10.22。任何偏离此组合的操作，都可能导致不可预知的依赖冲突或运行时错误。

2. 环境准备：在 Ubuntu 14.04 上构建一个“可控”的 PHP-Apache-Composer 三角

在 Ubuntu 14.04 上搭建 Silex，第一步不是敲 composer create-project ，而是亲手把地基夯平。因为系统自带的包管理器（APT）会给你一个看似完整、实则处处埋雷的环境：PHP 扩展缺位、Apache 模块未启用、Composer 版本错配。我们必须绕过 APT 的“便利”，用更底层、更确定的方式完成初始化。

2.1 PHP 安装与扩展校准：宁可手动编译，也不信 apt-cache show

Ubuntu 14.04 的 apt-get install php5 默认安装的是 PHP 5.5.9，这没错。但问题在于，它默认只装了最精简的核心模块，而 Silex 运行至少需要 mbstring （多字节字符串处理，用于路由参数解码）、 curl （如果项目后续要调用外部 API）、 json （配置解析与响应序列化）和 openssl （HTTPS 请求支持）。 apt-cache search php5- 列出的扩展包名，往往和 phpinfo() 显示的模块名不一致，比如 php5-mcrypt 在 PHP 5.6+ 已废弃，但在 5.5 下仍是必需的，而 apt-get install php5-mcrypt 却可能因源失效而失败。

我的做法是：先确认基础 PHP 是否可用：

sudo apt-get update && sudo apt-get install -y php5-cli php5-common
php5 -v  # 输出应为 PHP 5.5.9-1ubuntu4.29 (cli)

然后，逐个检查并安装关键扩展：

# 安装 mbstring（Silex 路由解析强依赖）
sudo apt-get install -y php5-mbstring
# 安装 curl（Silex 自身不直接用，但 skeleton 项目中的测试工具会用）
sudo apt-get install -y php5-curl
# 安装 json（PHP 5.5 内置，但需确认是否启用）
echo "<?php echo extension_loaded('json') ? 'enabled' : 'disabled'; ?>" | php5
# 若输出 disabled，则需编辑 /etc/php5/cli/php.ini，取消 ;extension=json.so 前的分号
sudo sed -i 's/;extension=json\.so/extension=json\.so/g' /etc/php5/cli/php.ini

最关键的 openssl 扩展，Ubuntu 14.04 的 php5-cli 包默认已包含，但 Apache 模块 ( libapache2-mod-php5 ) 使用的是另一套配置。必须确保两者一致：

# 检查 Apache 模块下的 openssl 状态
sudo a2enmod ssl
sudo service apache2 restart
# 创建一个 test.php 文件放在 /var/www/html/
echo "<?php print_r(openssl_get_cipher_methods()); ?>" | sudo tee /var/www/html/test.php
# 访问 http://localhost/test.php，若输出数组则说明生效；若报错，则需手动加载
echo "extension=openssl.so" | sudo tee -a /etc/php5/apache2/php.ini
sudo service apache2 restart

这个过程看似繁琐，但它解决了最隐蔽的坑：CLI 和 Web SAPI 使用不同的 php.ini 文件，导致你在命令行能跑通的代码，在浏览器里却因缺少某个扩展而崩溃。我曾因此浪费一整天，只因 mbstring 在 CLI 中启用，而在 Apache 中被注释掉了。

2.2 Apache 配置：从默认虚拟主机到 Silex 友好型重写

Ubuntu 14.04 的 Apache 默认配置（ /etc/apache2/sites-enabled/000-default.conf ）是为静态文件或传统 PHP 脚本设计的，它假设每个请求都对应一个物理 .php 文件。而 Silex 是单入口应用（Front Controller），所有请求都应被导向 web/index.php ，再由它内部的路由系统分发。这需要两个关键改动：启用 mod_rewrite 和配置正确的 Directory 权限。

首先，启用重写模块并重启：

sudo a2enmod rewrite
sudo service apache2 restart

接着，修改默认站点配置。不要直接编辑 000-default.conf ，而是创建一个独立的配置文件 /etc/apache2/sites-available/silex.conf ：

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    DocumentRoot /var/www/silex/web

    <Directory /var/www/silex/web>
        Options Indexes FollowSymLinks
        AllowOverride All  # 关键！允许 .htaccess 覆盖
        Require all granted  # Ubuntu 14.04 使用 Apache 2.4，语法与 2.2 不同
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/silex_error.log
    CustomLog ${APACHE_LOG_DIR}/silex_access.log combined
</VirtualHost>

这里有两个极易忽略的细节：

1. AllowOverride All ：这是 .htaccess 文件生效的前提。Silex 的 web/.htaccess 里有一行 FallbackResource /index.php ，它告诉 Apache，当找不到对应文件时，把请求交给 index.php 处理。没有 AllowOverride All ，这行配置就是废纸。
2. Require all granted ：这是 Apache 2.4 的新语法。如果你沿用旧教程里的 Order allow,deny + Allow from all ，Apache 会直接拒绝启动，并在错误日志里报 AH00526: Syntax error on line X of /etc/apache2/sites-available/silex.conf: Invalid command 'Order', perhaps misspelled or defined by a module not included in the server configuration 。

配置完成后，禁用默认站点，启用新站点：

sudo a2dissite 000-default.conf
sudo a2ensite silex.conf
sudo service apache2 reload

此时， /var/www/silex/web 目录就是你的 Web 根目录。所有对 http://localhost/xxx 的请求，都会先被 Apache 尝试匹配物理文件，匹配失败后，交由 web/index.php 处理。这就是 Silex 微框架得以运行的底层契约。

2.3 Composer 安装：为什么必须锁定在 1.x 系列

网络热词里反复出现 we're experiencing high demand for composer 2.5 right now. please switch to ，这恰恰反向印证了 Silex 与 Composer 2.x 的不兼容性。Composer 2.x 引入了全新的依赖解析引擎和插件架构，而 Silex v2.x 的 composer.json 文件格式、包命名空间（如 silex/silex vs silex/silex 的 PSR-4 自动加载规则）以及其依赖的 Symfony 组件版本，全部是为 Composer 1.x 设计的。强行使用 composer self-update 升级到 2.x，执行 create-project 时会立即报错：“The requested package silex/silex-skeleton could not be found in any version”。

因此，安装 Composer 的唯一正确姿势是： 下载并固定在 1.10.x 最终版 。

# 下载 Composer 安装脚本
curl -sS https://getcomposer.org/installer | sudo php5 -- --install-dir=/usr/local/bin --filename=composer
# 验证初始版本
composer --version  # 此时可能是 2.x，必须降级
# 强制回退到 1.10.22（Silex v2.3 兼容的最后一个稳定版）
sudo composer self-update --1
composer --version  # 输出应为 Composer version 1.10.22 2021-04-01 16:17:49

这个 --1 参数是 Composer 1.x 的专属开关，它会将 Composer 降级并锁定在 1.x 分支。这是 Ubuntu 14.04 环境下启动 Silex 的“生命线”。我见过太多人卡在这一步，反复尝试 composer create-project 失败后，转而去改 composer.json 的版本约束，结果越改越乱。记住：环境决定一切。在旧系统上，拥抱旧工具不是倒退，而是对现实的尊重。

3. 项目创建与骨架初始化：从空目录到可运行的 Hello World

当 PHP、Apache、Composer 全部就位，真正的“启动”才开始。这一步的目标很明确：在 /var/www/silex 目录下，生成一个结构清晰、开箱即用的 Silex 项目，并让它能在浏览器中输出 “Hello World”。但这个过程远非 composer create-project 一行命令那么简单，它涉及路径权限、Web 服务器用户隔离、以及对 Silex 骨架结构的深度理解。

3.1 创建项目：选择骨架与规避网络陷阱

Silex 官方提供了 silex-skeleton 作为标准起步模板。它的优势在于预置了合理的目录结构（ src/ , web/ , tests/ ）、基础的 index.php 入口、以及一个演示用的 HelloController 。但直接执行 composer create-project silex/silex-skeleton /var/www/silex 会遇到两个现实障碍：

1. 权限问题 ： /var/www/ 目录默认属于 root:www-data ，而普通用户（如 ubuntu ）没有写入权限。 composer 以当前用户身份运行，会报 Permission denied 。
2. 网络稳定性 ： silex/silex-skeleton 的 GitHub 仓库在 2023 年后已归档（Archived），Packagist 上的包信息虽仍存在，但源码下载链接可能指向已关闭的镜像。

我的解决方案是“两步走”：先用 sudo 创建项目，再调整所有权；并使用 Packagist 的稳定缓存地址，绕过 GitHub 直连。

# 1. 切换到 root 用户，避免权限问题
sudo su -
# 2. 创建项目（指定 --no-interaction 避免交互式提问）
composer create-project silex/silex-skeleton /var/www/silex --no-interaction --stability=stable
# 3. 退出 root，将项目所有权还给 www-data（Apache 运行用户）和你的开发用户
exit
sudo chown -R www-data:www-data /var/www/silex
sudo chown -R $USER:www-data /var/www/silex
# 4. 设置合理的目录权限（755 对目录，644 对文件）
sudo find /var/www/silex -type d -exec chmod 755 {} \;
sudo find /var/www/silex -type f -exec chmod 644 {} \;
# 5. 特别设置 web/ 目录的写权限（Silex 日志、缓存会写入此处）
sudo chmod 775 /var/www/silex/web

这个流程确保了 Apache（以 www-data 用户身份）能读取所有 PHP 文件，并能向 web/ 目录写入日志和缓存，而你的开发账户（ $USER ）也能自由编辑代码。这是生产环境部署前必须完成的“最小权限”校准。

3.2 理解骨架结构： web/index.php 是唯一的门

Silex 骨架的精髓，全在 web/index.php 这个不到 30 行的文件里。它不是简单的“加载框架”，而是一系列精心设计的引导步骤。我们来逐行拆解其工作原理：

<?php
// 1. 设置错误报告级别，确保开发时能看到所有警告
error_reporting(E_ALL);
ini_set('display_errors', 1);

// 2. 定义常量，指明应用根目录（/var/www/silex）和 Web 根目录（/var/www/silex/web）
define('ROOT_DIR', __DIR__.'/..');
define('WEB_DIR', __DIR__);

// 3. 加载 Composer 自动加载器，这是所有类加载的起点
require_once ROOT_DIR.'/vendor/autoload.php';

// 4. 创建 Silex 应用实例，这是整个框架的“心脏”
$app = new Silex\Application();

// 5. 注册核心服务提供者，例如 Twig 模板引擎（如果需要）
// $app->register(new Silex\Provider\TwigServiceProvider(), array(
//     'twig.path' => __DIR__.'/../views',
// ));

// 6. 定义第一个路由：GET /hello/{name}，返回一个响应对象
$app->get('/hello/{name}', function ($name) use ($app) {
    return $app->json(array('message' => 'Hello '.$name));
});

// 7. 运行应用，处理当前 HTTP 请求并发送响应
$app->run();

这段代码揭示了 Silex 的核心哲学： 一切皆为可调用对象（Callable） 。 $app->get() 的第二个参数不是一个字符串，而是一个匿名函数（Closure）。这个函数接收路由参数 $name ，并利用 $app 实例的 json() 方法，构造并返回一个 Symfony\Component\HttpFoundation\JsonResponse 对象。 $app->run() 则是整个请求生命周期的终结者，它会解析 $_SERVER 变量，调用匹配的路由函数，并将返回的响应对象通过 header() 和 echo 发送给客户端。

理解这一点至关重要。它意味着你不需要学习复杂的控制器继承体系，只需要写出符合签名的函数即可。这也是为什么 Silex 被称为“微框架”——它的 API 极其精炼，几乎没有抽象层。当你看到 return $app->json(...) 时，你看到的不是魔法，而是对 Symfony HttpFoundation 组件的直接封装。

3.3 测试与验证：从命令行到浏览器的全链路检查

项目创建完毕，不能只靠 php web/index.php 命令行测试。必须完成从 Apache 接收请求，到 PHP 解析，再到 Silex 路由匹配的全链路验证。

第一步：CLI 测试（快速排除 PHP 语法错误）

cd /var/www/silex
php web/index.php
# 如果输出 "Hello World" 或类似 JSON，说明 PHP 解析无误
# 如果报错，重点检查 vendor/autoload.php 路径和 PHP 扩展

第二步：Apache 静态文件测试（验证 Web 服务器配置）

在 web/ 目录下创建一个 test.html ：

echo "<h1>Apache is working!</h1>" | sudo tee /var/www/silex/web/test.html

访问 http://localhost/test.html 。如果看到标题，证明 Apache 的 DocumentRoot 和 Directory 权限配置正确。

第三步：Silex 路由测试（终极验证）

删除 test.html ，直接访问 http://localhost/hello/world 。如果浏览器返回 {"message":"Hello world"} ，恭喜，你的 Silex 环境已经完全打通。如果返回 404，检查点如下：

• .htaccess 文件是否存在且内容正确？标准内容应为：

  FallbackResource /index.php
  

• Apache 的 AllowOverride All 是否已生效？检查 /etc/apache2/sites-enabled/silex.conf 。
• web/index.php 文件的首行 <?php 是否被意外修改为 <? （短标签）？Ubuntu 14.04 默认禁用短标签，必须使用完整标签。

我曾在一个客户的服务器上，因为 web/index.php 被编辑器自动转换了行尾符（CRLF），导致 Apache 报 Invalid command '\r' 错误。这种低级错误，在老旧环境中尤为常见，必须养成用 file web/index.php 命令检查文件类型的习惯。

4. 核心功能实现与调试：让 Silex 不再只是“Hello World”

一个能输出 “Hello World” 的 Silex 应用，就像一辆能点火但不能挂挡的汽车。真正的价值在于它如何处理真实需求：连接数据库、渲染 HTML 页面、处理表单提交、管理用户会话。在 Ubuntu 14.04 的限制下，这些功能的实现方式，与现代 PHP 开发有显著差异，必须采用“向后兼容”的策略。

4.1 数据库集成：PDO 与 MySQL 的经典组合

Silex 本身不提供数据库抽象层，它鼓励你使用 PHP 原生的 PDO（PHP Data Objects）扩展。Ubuntu 14.04 的 php5-mysql 包已过时，且不支持 MySQLi 的面向对象接口，因此 PDO 是唯一可靠的选择。

首先，确保 PDO 和 MySQL 驱动已安装：

sudo apt-get install -y php5-mysqlnd  # mysqlnd 是 MySQL Native Driver，比旧的 libmysql 更稳定
# 验证
php5 -m | grep pdo_mysql  # 应输出 pdo_mysql

然后，在 web/index.php 中注册 PDO 服务：

// 在 $app = new Silex\Application(); 之后添加
$app->register(new Silex\Provider\DoctrineServiceProvider(), array(
    'db.options' => array(
        'driver'   => 'pdo_mysql',
        'host'     => '127.0.0.1',
        'dbname'   => 'silex_demo',
        'user'     => 'root',
        'password' => '',
        'charset'  => 'utf8',
    ),
));

// 创建一个数据库表（仅首次运行）
$app->get('/setup', function () use ($app) {
    $sql = "CREATE TABLE IF NOT EXISTS users (
        id INT AUTO_INCREMENT PRIMARY KEY,
        name VARCHAR(255) NOT NULL,
        email VARCHAR(255) UNIQUE NOT NULL
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8";
    $app['db']->executeUpdate($sql);
    return "Database table created.";
});

这里的关键是 Silex\Provider\DoctrineServiceProvider 。它并非完整的 Doctrine ORM，而是一个轻量级的 Doctrine DBAL（Database Abstraction Layer）包装器，专为 Silex 设计。它将 $app['db'] 注册为一个服务，你可以像调用方法一样使用 $app['db']->fetchAssoc() , $app['db']->insert() 等。

注意： php5-mysqlnd 包在 Ubuntu 14.04 的源中可能名为 php5-mysql ，但实际安装的是 mysqlnd 。如果 apt-get install php5-mysql 失败，请尝试 apt-get install php5-mysqlnd 或 apt-get install php5-mysql 并检查 /etc/php5/mods-available/ 目录下是否有 mysql.ini 和 mysqlnd.ini 。

4.2 模板渲染：Twig 的极简集成

Silex 骨架默认不包含模板引擎，但 Twig 是事实上的标准。集成它需要两步：安装 Twig 包，并注册 Twig 服务提供者。

# 在项目根目录下，使用 Composer 安装 Twig
cd /var/www/silex
sudo -u www-data composer require twig/twig:^1.44  # Twig v1.x 是 PHP 5.5 兼容的最后一个大版本

然后，在 web/index.php 中注册：

// 在 require_once ROOT_DIR.'/vendor/autoload.php'; 之后添加
$app->register(new Silex\Provider\TwigServiceProvider(), array(
    'twig.path' => __DIR__.'/../views',
    'twig.options' => array('cache' => __DIR__.'/../cache/twig'),
));

// 创建 views/ 和 cache/twig/ 目录
sudo mkdir -p /var/www/silex/views /var/www/silex/cache/twig
sudo chown -R www-data:www-data /var/www/silex/cache

最后，定义一个使用 Twig 的路由：

$app->get('/greet/{name}', function ($name) use ($app) {
    return $app['twig']->render('greet.twig', array('name' => $name));
});

并在 views/greet.twig 中创建模板：

<!DOCTYPE html>
<html>
<head><title>Greeting</title></head>
<body>
    <h1>Hello {{ name }}!</h1>
    <p>This page was rendered by Twig.</p>
</body>
</html>

这个例子展示了 Silex 的“按需加载”哲学。你不需要一开始就引入所有组件，而是根据功能需求，一个一个地 register 服务。这种模式让应用保持轻量，但也要求开发者对每个服务的生命周期和配置选项有清晰认知。

4.3 调试与日志：在无 GUI 环境下定位问题

Ubuntu 14.04 通常以 Server 版本运行，没有图形界面，因此调试不能依赖 Xdebug 或 IDE 的断点。必须依靠日志和命令行工具。

Silex 提供了内置的 MonologServiceProvider ，可以将日志输出到文件：

$app->register(new Silex\Provider\MonologServiceProvider(), array(
    'monolog.loglevel' => \Monolog\Logger::DEBUG,
    'monolog.name' => 'silex_app',
    'monolog.level' => \Monolog\Logger::DEBUG,
    'monolog.path' => __DIR__.'/../logs/app.log',
));

// 在路由中记录日志
$app->get('/logtest', function () use ($app) {
    $app['monolog']->addDebug('This is a debug message.');
    return "Logged.";
});

同时，Apache 的错误日志是黄金信息源：

# 实时跟踪 Apache 错误日志
sudo tail -f /var/log/apache2/silex_error.log
# 查看最近 10 行
sudo tail -n 10 /var/log/apache2/silex_error.log

一个经典的调试场景是：路由函数执行了，但页面空白。此时， tail -f 日志会立刻显示 PHP Fatal error: Call to undefined function ... ，从而快速定位缺失的 PHP 扩展或拼写错误。这种“日志驱动”的调试方式，是运维老手的必备技能，它比任何 IDE 都更直接、更可靠。

5. 生产环境加固与常见故障排查：让 Silex 在旧系统上稳定运行

当 Silex 应用在开发环境下跑通，下一步就是思考它如何在生产环境中“活下来”。Ubuntu 14.04 的老旧特性既是挑战，也是机遇——它迫使你直面 Web 应用最底层的运行逻辑，而不是依赖现代框架的自动化保护。

5.1 安全加固：关闭危险的 PHP 配置

Ubuntu 14.04 的默认 PHP 配置，为向后兼容保留了一些在今天看来极度危险的选项。在生产环境中，必须手动关闭它们：

# 编辑 CLI 和 Apache 的 php.ini
sudo nano /etc/php5/cli/php.ini
sudo nano /etc/php5/apache2/php.ini

找到并修改以下行：

; 关闭危险的远程文件包含（防止任意文件读取/执行）
allow_url_fopen = Off
allow_url_include = Off

; 关闭错误信息暴露（防止泄露路径、版本等敏感信息）
display_errors = Off
display_startup_errors = Off
log_errors = On

; 限制脚本最大执行时间，防止恶意死循环
max_execution_time = 30

; 限制内存使用，防止内存耗尽
memory_limit = 128M

修改后，重启 Apache：

sudo service apache2 restart

这些配置不是“可选优化”，而是生产环境的底线。 allow_url_include = On 曾是 PHP 早期 RCE（远程代码执行）漏洞的温床，而 display_errors = On 则会让 phpinfo() 的输出直接暴露在攻击者面前。

5.2 故障排查：一份基于真实日志的排错清单

在 Ubuntu 14.04 + Silex 的组合中，90% 的问题都能通过三份日志定位：Apache 错误日志、PHP 错误日志、以及 Composer 的详细输出。下面是一份按现象分类的排错清单，每一条都来自我处理过的实际工单：

这份清单的价值不在于穷举所有错误，而在于它建立了一种 日志优先的排错范式 。在资源受限的旧系统上，你没有时间去猜，只能让日志告诉你真相。

5.3 性能与维护：为“遗产系统”设计的可持续方案

Silex 项目一旦上线，就进入了漫长的维护周期。在 Ubuntu 14.04 这样的 EOL 系统上，维护的核心原则是： 最小化变更，最大化监控 。

• 不升级框架 ：Silex v2.3 是终点，不要再尝试升级到 v3（它要求 PHP 7.1+）。任何“升级”都是重构，成本远高于收益。

• 监控关键指标 ：编写一个简单的 Bash 脚本，定期检查 Apache 进程数、PHP 错误日志增长速率、磁盘空间：

  #!/bin/bash
  # /usr/local/bin/silex-monitor.sh
  echo "$(date): Apache processes: $(ps aux | grep apache2 | wc -l)"
  echo "$(date): Error log size: $(du -h /var/log/apache2/silex_error.log | cut -f1)"
  echo "$(date): Disk usage: $(df -h /var/www | tail -1 | awk '{print $5}')"
  

  将其加入 crontab，每 5 分钟执行一次，输出追加到 /var/log/silex-monitor.log 。

• 备份策略 ：每天凌晨 2 点，自动备份 /var/www/silex 目录和 MySQL 数据库：

  0 2 * * * tar -czf /backup/silex-$(date +\%F).tar.gz /var/www/silex && mysqldump -u root silex_demo > /backup/silex_db_$(date +\%F).sql
  

这些看似“土味”的运维脚本，恰恰是保障一个老旧系统长期稳定运行的基石。它们不炫技，但有效；不依赖新工具，但可靠。在技术迭代的洪流中，有时最朴素的方法，才是最坚固的堤坝。

我在为客户维护一个运行了 7 年的 Silex 应用时，最后总结出的经验只有一条： 不要试图用新世界的规则去改造旧世界，而是学会用旧世界的语言，讲好新世界的故事。 Ubuntu 14.04 是一个时代的句点，Silex 是那个时代最优雅的注脚。启动它，不是为了回到过去，而是为了理解，那些被我们习以为常的现代框架，其底层的每一次呼吸，都源于这些被时光尘封的、精妙而坚韧的设计。