应选longtext字段，因text仅64KB易致截断或报错；需显式声明、禁用自动过滤、避免like查询、添加摘要字段索引、调大max_allowed_packet并确保UTF8MB4字符集。
ThinkPHP 里 text 和 longtext 字段怎么选？
MySQL 的 text 最大 64KB，longtext 是 4GB——但 ThinkPHP 不会自动帮你选。默认用 text 建模时，一旦存入超长富文本、日志片段或用户粘贴的代码块，就会触发 Packet for query is too large 或静默截断。
- 实际项目中，只要字段可能存 Markdown 源码、带样式的 HTML 片段、或用户上传的 JSON 日志，就该直接设为
longtext - ThinkPHP 迁移文件里写
$table->text('content')是不够的，得显式写$table->longText('content') - 模型验证层别只校验「非空」或「最大长度 1000」，那跟字段类型不匹配，校验形同虚设
模型赋值时大字段被自动 trim 或转义怎么办？
ThinkPHP 默认对字符串字段启用 htmlspecialchars 转义（尤其在使用 create() 或批量赋值时），富文本里的 <script>、<style> 标签会被吃掉；更隐蔽的是，某些 MySQL 配置下，末尾空格和换行会被 trim() 掉，导致 Markdown 缩进失效。
- 关键动作：在模型里关掉自动过滤，加
protected $filter = [];，或针对字段单独禁用：protected $filter = ['content' => '']; - 不要用
$model->data($data, true)的严格模式处理含 HTML 的字段，它会强制调用think\helper\Str::clean - 如果必须保留过滤逻辑，把大字段挪到
save()前手动赋值：$model->content = $raw_html;，绕过自动处理链
where 查询含大字段的记录为什么变慢？
MySQL 对 text/longtext 字段无法建完整索引，但 ThinkPHP 的 where('content', 'like', '%关键词%') 会直接扫全表——尤其当内容平均 50KB、表有 10 万行时，单查秒变 3 秒以上。
- 别在大字段上做
like模糊查，改用全文索引：ALTER TABLE <code>articleADD FULLTEXT(content);，然后用where('MATCH(content) AGAINST(? IN NATURAL LANGUAGE MODE)', [$kw]) - 更现实的做法是：额外加一个
content_digest字段（varchar(500)），存前 200 字 + 关键词哈希，在它上面建普通索引做前置筛选 - 注意
find()和select()默认查全部字段，大字段拖慢网络传输；明确指定需要的字段：field('id,title,created_at')
数据库备份/迁移时大字段导出失败怎么救？
mysqldump 默认 --max-allowed-packet=4M，而一条 longtext 记录可能占 8MB，dump 直接报错 Got a packet bigger than 'max_allowed_packet' bytes，且 ThinkPHP 的命令行迁移工具不会提示这个底层限制。
立即学习“PHP免费学习笔记（深入）”；
- 导出前先调大参数：
mysqldump --max-allowed-packet=256M -u root ... - 迁移 SQL 文件若含大字段，别用 ThinkPHP 的
Db::execute()直接执行，它走 PDO 默认配置；改用系统命令分段导入，或先用LOAD DATA INFILE加载原始数据 - 测试环境导入时容易忽略字符集问题：
longtext存 UTF8MB4 内容，但 dump 文件头没声明SET NAMES utf8mb4，会导致乱码——不是 ThinkPHP 的锅，但你得补上
大字段本身不难存，难的是从建表、赋值、查询到运维整个链路里，每个环节都默认“看不见”它的体积。最容易漏的是备份和测试导入，一跑就卡住，又查不到报错源头。
