Laravel 的 encrypted 类型自动加解密依赖底层加密负载完整性，若数据库字段长度不足导致截断，将触发 “The payload is invalid” 错误；根本解决方式是扩大字段长度（推荐 TEXT），而非修改访问逻辑或绕过 Eloquent 铸造机制。
laravel 的 `encrypted` 类型自动加解密依赖底层加密负载完整性，若数据库字段长度不足导致截断，将触发 “the payload is invalid” 错误；根本解决方式是扩大字段长度（推荐 `text`），而非修改访问逻辑或绕过 eloquent 铸造机制。
在 Laravel 中使用 encrypted 铸造类型时，框架会自动对字段值进行 AES-256-CBC 加密（配合 APP_KEY）并 Base64 编码后存入数据库。关键点在于：加密后的字符串远长于原始明文。例如：
- 明文 "hello"（5 字符）加密后约 160 字符；
- 明文 200 字符 → 加密后达 568 字符（Laravel 9 实测）；
- 明文 300 字符 → 加密后超 740 字符。
而你当前使用的 VARCHAR(191) 列类型严重不足——即使最短的有效加密载荷也常超过 200 字符，字段截断直接破坏 Base64 编码结构和 MAC 签名，导致 decrypt() 抛出 DecryptException: The payload is invalid。
✅ 正确解决方案（迁移 + 验证）：
-
升级数据库字段类型（推荐 TEXT，兼容任意长度）：
// 在 migration 中 Schema::table('integrations', function (Blueprint $table) { $table->text('service_username')->change(); $table->text('service_password')->change(); $table->text('service_practice_pin')->change(); });
⚠️ 注意：CHANGE 语法需启用 doctrine/dbal 扩展；若不可用，改用 DROP + ADD 组合，或直接执行原生 SQL。
- 确认加密配置一致性：
- 确保 APP_KEY 自应用部署以来从未变更（变更会导致历史数据无法解密）；
- 避免在 .env 中使用带空格或特殊字符的 APP_KEY（应为 32 字节随机字符串，如 php artisan key:generate 生成）。
- 无需自定义 accessor： 你尝试的 getDecryptedServiceUsernameAttribute() 仍调用 decrypt()，但底层数据已被截断，故无效。修复字段长度后，$integration->service_username 将自动解密返回明文，完全符合 Eloquent 铸造预期。
❌ 不推荐的替代方案：
- 改用 VARCHAR(1000) 等固定长度 → 仍有上限风险；
- 手动 Crypt::encrypt()/decrypt() 存取 → 绕过铸造机制，丧失自动性与一致性；
- 存储明文 → 违反安全最佳实践，绝不允许。
? 额外建议：对敏感凭证类字段，可结合 Laravel 的 EncryptedString（Laravel 10+）或自定义 EncryptedCast 增强类型安全；生产环境务必启用 APP_DEBUG=false，避免泄露加密异常堆栈。
修复后验证流程：
$integration = Integration::first(); dump($integration->service_username); // ✅ 应输出原始用户名（非 null 或异常）
字段扩容是唯一治本之策——让加密载荷完整落库，Eloquent 才能正确还原。
