ThinkPHP默认不提供Flyweight支持，因其核心设计侧重快速开发与运行时灵活性，对象由容器管理且默认非单例，而享元模式要求内部状态不可变、工厂全局唯一、外部状态完全由调用方传入，与框架常见的带上下文初始化习惯冲突。
直接说结论：在 ThinkPHP 项目中，Flyweight 享元模式不是框架内置能力，也不能靠配置开关启用；它必须手动实现、严格区分内外状态，并且只在「大量对象共享相同内部数据」的特定场景下才真正节省内存——否则反而增加复杂度和间接开销。
为什么ThinkPHP默认不提供Flyweight支持？
ThinkPHP 的核心设计偏向快速开发与运行时灵活性，对象生命周期由容器管理（如 Container），但其默认行为是每次解析都可能新建实例（除非显式绑定为单例）。而 Flyweight 要求：内部状态不可变、工厂全局唯一、外部状态完全由调用方传入。这与 ThinkPHP 常见的「对象带业务上下文初始化」习惯冲突。
常见误用现象：
- 把 Db::name('user')->find() 返回的模型当成可享元对象（错：每条记录的 ID、name 等都是不同内部状态）
- 在控制器里 new 一个类并试图复用（错：没走工厂，无法去重）
- 将含数据库连接、请求上下文的 Service 类强行做成享元（错：违反不可变性，引发状态污染）
哪些 ThinkPHP 场景适合手写 Flyweight？
满足以下全部条件时才值得引入：
- 对象创建开销大（如解析 SVG 字符串、加载字体元数据、构建 icon 配置）
- 内部状态组合有限（例如只有
['success', 'error', 'warning']三种图标类型 +[16, 24, 32]三种尺寸） - 外部状态明确分离（如渲染坐标
$x,$y、用户主题色$theme等，不存于对象内） - 对象被高频调用（单次请求中 >100 次实例化同类对象）
典型例子：
- 后台权限系统中，成百个菜单项共用同一套图标定义（IconFlyweight::get('setting', 'line', 24)）
- 富文本编辑器渲染时，对重复出现的字符样式（如 font-family: "PingFang SC", sans-serif）做享元缓存
- 日志格式化器中，固定格式模板（'[%s][%s] %s'）作为内部状态，时间戳和内容为外部状态
如何在 ThinkPHP 里安全落地 Flyweight？
关键不是“加个类”，而是控制三件事：工厂单例、对象不可变、外部状态零存储。
立即学习“PHP免费学习笔记（深入）”；
示例结构（放在 app/common/flyweight/ 下）：
class IconFlyweight
{
public function __construct(
public readonly string $type,
public readonly string $style,
public readonly int $size
) {}
<pre class="brush:php;toolbar:false;">public function render(int $x, int $y, string $color): string
{
return "<svg class=\"icon-{$this->type}\" style=\"color:{$color}\" x=\"{$x}\" y=\"{$y}\">...</svg>";
}}
class IconFlyweightFactory { private static array $pool = [];
public static function get(string $type, string $style, int $size): IconFlyweight
{
$key = md5("{$type}:{$style}:{$size}");
return self::$pool[$key] ??= new IconFlyweight($type, $style, $size);
}}
使用方式（在控制器或服务中）：
- 不要 new，始终走
IconFlyweightFactory::get() - 确保
$type,$style,$size是简单标量，避免传数组或对象导致 key 不稳定 - 所有动态参数（
$x,$y,$color）必须在render()时传入，不能存为属性 - 若需跨请求共享（如 CLI 命令长时间运行），注意静态属性不会自动 GC，必要时加
clear()方法
比 Flyweight 更现实的 ThinkPHP 内存优化点
多数 ThinkPHP 内存问题其实不出在对象数量，而出在数据加载和生命周期管理：
- 用
yield替代select()处理大批量数据（Db::cursor()或生成器查询） - 禁用不必要的模型事件监听（
Model::observe()注册后不取消会持续驻留） - 模板中避免
{volist name="list" id="item"}{php}new SomeHeavyClass(){/php}{/volist}这类写法 - 关闭调试模式后仍开启 trace 日志（
app_trace）会导致内存累积 - 自定义命令未调用
unset($model)或gc_collect_cycles()，尤其在循环处理文件时
真正需要 Flyweight 的地方很少；但一旦需要，它的不可变性和工厂隔离就是硬边界——跨过这条线，就不是优化，而是埋雷。
