pint 默认仅扫描app/、config/、database/、routes/、tests/五个目录的php文件；若路径正确却未格式化，需检查是否在默认目录外、文件未git add、存在语法错误、或误配pint.json导致规则失效。
它默认就能修，但修不修得到，取决于你有没有踩中那几个静默失效点。
为什么 pint 没动我刚写的 app/Http/Controllers/Api/V1/UserController.php
文件路径没错、PHP 语法也没问题，但它就是没格式化——大概率是被默认扫描范围拦住了。Pint 只认这五个目录：app/、config/、database/、routes/、tests/，且只处理其中的 PHP 文件。
- 检查是否拼错路径：比如写成
app/Http/Controller（少了个s）或App（大小写敏感） - 确认文件已
git add：如果用了--dirty参数，未暂存的新文件会被跳过 - 留意静默失败：文件里有语法错误（如漏掉
}或在 PHP 8.0 环境用了??），Pint 不报错，直接跳过解析 - Blade、JS、JSON 文件永远不会被碰——这不是 bug，是设计
pint.json 一加就全乱套了
只要项目根目录存在 pint.json，Pint 就彻底放弃内置 preset，所有规则、路径、排除项都必须显式声明，不会合并、不会继承、也不会 fallback。
-
"paths"必须列全：想加scripts/，就得写["app", "config", "database", "routes", "tests", "scripts"]，不能只写["scripts"] -
"exclude"是精确匹配，不支持通配符：写"exclude": ["migrations"]才能跳过database/migrations，写"database/migrations"无效 - 别混用
"preset"和"rules"：一旦定义"rules"，"preset"仅用于兜底，其他规则全失效 -
pint.json必须是小写、无 BOM、无注释、严格 JSON 格式，否则静默回退到默认行为
--test 和 --repair 在 CI 里总失败，但本地能过
根本不是规则写错了，而是环境不一致导致 Pint 压根没跑起来，或者跑了但没读到该读的东西。
-
Could not open input file: vendor/bin/pint：CI 中composer install用了--no-dev，或者缓存复用了旧vendor/（composer.lock没变但laravel/pint版本已升） -
PHP version is lower than required：Pint v1.x 强制要求 PHP 8.1+，CI 镜像若还是 8.0，命令直接退出 - Linux 下权限缺失：GitHub Actions 或 GitLab CI 中，
vendor/bin/pint缺执行权限，得先chmod +x vendor/bin/pint -
--test适合 CI：它“零容忍”，发现任何风格问题就返回非零码；--repair是“尽力而为”，修复后仍有不可修问题才报错，CI 里容易漏检
想让 pint 处理 resources/js 或自定义规则？别试了
Pint 只处理 PHP 文件，且只走自己那套规则加载逻辑。它不读 .php-cs-fixer.php，也不管 JS、CSS、Blade、JSON。
- JS/TS 代码统一请用
ESLint+Prettier，不是 Pint 的事 - 想强制短数组语法？只能通过
pint.json加"array_syntax": {"syntax": "short"}，别指望 CLI 参数覆盖 - IDE 保存时自动格式化？VSCode 要装 PHP Intelephense 或 PHP CS Fixer 插件，单独配置，和
pint命令无关 - Git pre-commit 钩子里调用
pint，务必加--test并检查退出码，否则钩子可能不阻断违规提交
最常被忽略的是：Pint 的“开箱即用”只对默认结构有效；一旦你动了 pint.json，它就变成一个完全手动管理的工具，没有中间态，也没有容错提示。
