直接用 Security::generateRandomString() 生成密码学安全随机字符串，它基于 random_bytes()，返回 URL-safe 的 base64-like 字符串（a-z, A-Z, 0-9, -, _），长度默认32，不支持自定义字符集，适用于 token、重置码等场景。
直接用 Security::generateRandomString() 就行，别自己写 rand() 或 mt_rand()
Yii 的 Security::generateRandomString() 是安全可靠的随机字符串生成器，底层调用的是 PHP 的 random_bytes()（PHP 7+）或兼容 fallback，不是伪随机函数。自己用 rand()、mt_rand() 或 uniqid() 拼接，容易被预测，尤其在生成 token、密码重置码、API key 等场景下有风险。
常见错误现象：Security::generateRandomString(16) 返回空、抛出 Exception: Unable to generate a random string —— 多半是 PHP 缺少 openssl 或 mcrypt（旧版），或者运行在严重受限的环境（如某些共享主机禁用了加密函数）。
- 确保 PHP 已启用
openssl扩展（推荐）；mbstring也建议开启，否则非 ASCII 字符处理可能异常 - 不传参默认长度是 32；传入整数即可，比如
Security::generateRandomString(12) - 该方法**不接受字符集参数**，返回的是 base64-safe 字符串（a-z, A-Z, 0-9, - 和 _），不含特殊符号或换行
generateRandomString() 生成的字符串能直接当 token 用吗？
可以，但得看用途。它生成的是密码学安全的随机字节再经 base64_encode() 后截断处理，结果可读、URL-safe、无歧义字符（没 +、/、=），适合用在 URL 参数、HTTP header、数据库 token 字段里。
使用场景举例：生成一次性登录链接 token、临时密码重置码、CSRF salt、缓存键后缀。
- 如果需要固定长度且严格 0–9/a–z/A–Z（比如老系统只认这 62 个字符），得自己做一次过滤或重写逻辑，
generateRandomString()本身不提供字符集定制 - 不要用它生成「人类可读」的验证码（比如“AB3X”这种），那是
Security::generatePasswordHash()或专用库的事 - 性能没问题：单次调用耗时在微秒级，比自己拼接 + hash 快且更安全
为什么有时候在 console 应用里调用报错，而 web 应用正常？
根本原因不是 Yii 区分环境，而是 CLI 模式下 PHP 的 OpenSSL 配置或权限可能不同。典型表现是 CLI 下执行 php yii test/generate-token 报 Failed to generate random bytes，但浏览器访问同一个 action 却成功。
- 检查 CLI 使用的 PHP 配置：运行
php -i | grep openssl，确认OpenSSL support => enabled - 某些 Docker 容器或 Alpine Linux 默认不装
openssl扩展，需显式安装php7-opcache和php7-openssl（包名依发行版而异） - 极少数情况是 /dev/urandom 不可读（如容器挂载了只读文件系统），这时 Yii 会 fallback 到
mcrypt_create_iv()，若也没则彻底失败
替代方案：不想依赖 Yii Security 怎么办？
如果你的项目没用 Yii，或想解耦，最稳妥的替代就是直接用 PHP 原生函数：bin2hex(random_bytes(16)) 或 base64_encode(random_bytes(12))。注意别用 str_shuffle() 或 array_rand() —— 它们不安全。
兼容性提醒：PHP random_bytes()，必须升级或引入 paragonie/random_compat（Yii 2.0.13+ 内部已用它做 polyfill）。
真正容易被忽略的是：哪怕你用了 generateRandomString()，如果后续把它转成大写、再 trim、再拼接时间戳，就可能破坏熵值。随机性只存在于原始输出那一刻，任何确定性变换都可能引入偏差。
