最稳妥方式是执行 composer require twig/twig，Composer 自动安装最新稳定版 v3.x 并处理依赖；需注意网络、PHP 版本（≥7.2.5）、路径真实可读、cache/debug 环境配置及 |raw 过滤器的安全边界。
直接执行 composer require twig/twig 就能装好
这是最稳妥、最主流的方式，Composer 会自动下载最新稳定版（v3.x），同时写入 composer.json 并生成 vendor/autoload.php。你不需要手动 require 类文件，也不用管依赖冲突——Composer 全都处理好了。
常见错误现象：Could not find package twig/twig 多半是网络问题（尤其国内）；your requirements could not be resolved 则常因 PHP 版本太低（Twig v3 要求 ≥ 7.2.5）或已有其他模板引擎锁定了旧版本。
- 若用 PHP 7.1 或更老版本，改用
composer require "twig/twig:^2.15" - 若网络慢，可临时换国内镜像：
composer config -g repo.packagist composer https://packagist.phpcomposer.com（注意该镜像已停用，推荐用阿里云：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/） - 安装后务必确认
vendor/twig/twig目录存在，且vendor/autoload.php可被正常引入
FilesystemLoader 的路径必须真实存在且可读
初始化 Twig 时最常出错的地方不是语法，而是路径：比如写成 new \Twig\Loader\FilesystemLoader('templates')，但项目根目录下根本没有 templates/ 这个文件夹，或者权限不够（Linux 下 Web 服务器用户如 www-data 没有读取权）。
使用场景：开发阶段建议把模板放在项目根目录的 views/ 或 templates/ 下，和代码逻辑分离；生产环境可统一放在 resources/views/ 等规范路径。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 路径支持数组，例如
new \Twig\Loader\FilesystemLoader(['templates', 'shared_templates'])，Twig 会按顺序查找 - 绝对路径更可靠：
__DIR__ . '/templates'，避免相对路径随工作目录变化失效 - 如果模板路径含中文或特殊字符，确保文件系统编码与 PHP 一致（UTF-8），否则可能报
Unable to find template
cache 和 debug 不是可选项，而是环境开关
这两个配置项直接影响开发效率和线上稳定性，不是“开了更好”，而是“开错就出事”：
- 开发时设
'cache' => false，否则改了模板不生效；但别在prod环境留着它，否则每次请求都重新编译，性能断崖式下跌 -
'debug' => true才能用{{ dump() }}查变量，但上线前必须关掉，否则可能泄露敏感数据（如数据库配置、用户 token） - 缓存目录（如
'cache' => __DIR__ . '/var/cache/twig'）需提前创建，并确保 Web 服务器进程有写权限；否则 Twig 会静默失败或抛出Twig\Error\RuntimeError
模板里用 {{ name }} 安全，但想输出 HTML 得加 |raw
Twig 默认对所有变量输出做 HTML 转义（ → <code><），这是防 XSS 的核心机制。所以当你传入一段带标签的富文本（比如后台编辑器存的 <p>Hello</p>），直接 {{ content }} 会原样显示为文字，而不是渲染成段落。
这时得用过滤器：{{ content|raw }}。但要注意：
-
|raw绕过所有安全防护，只可用于完全可信的内容（如你自己硬编码的 HTML、或经strip_tags()+ 白名单过滤后的字符串） - 不要对用户输入（如
$_POST['bio']）直接|raw，否则等于打开 XSS 后门 - 需要动态拼接 HTML？优先考虑用
{% include %}拆分成受控子模板，而不是在 PHP 层拼字符串再传给模板
|raw 的信任边界——它们不出错时毫无存在感，一出就是线上事故。 
