README必须明确写出composer require完整命令及依赖要求，如“composer require monolog/monolog:^3.0（Requires PHP >= 8.1 and ext-json）”，并确保版本、命名空间、示例代码与composer.json严格一致。
README里必须写清楚composer require命令怎么用
用户装包的第一步就是执行composer require，但很多人只写composer require vendor/package，漏掉关键细节。比如包是否支持PHP 8.2、是否要求ext-curl，这些不写清楚，别人一装就报Your requirements could not be resolved。
实操建议：
- 在“Installation”小节第一行直接给出完整命令，例如：
composer require monolog/monolog:^3.0（带版本约束） - 紧跟着用一句话说明最低PHP版本和必需扩展，例如：“Requires PHP >= 8.1 and
ext-json” - 如果包有可选依赖（如
ext-xml用于某功能），单独列在“Optional extensions”下，别混进主安装说明
示例代码必须能直接复制粘贴运行
很多README里的代码示例看着对，一跑就错——不是少use语句，就是类名写成旧版，或者用了只有Laravel环境下才有的辅助函数。
实操建议：
- 所有代码块以最小可行单元呈现，比如用
MonologLogger就只use这一行，不塞一堆无关use - 避免使用框架专属语法（如
app()、resolve()），改用标准实例化：$logger = new Logger('name'); - 如果示例依赖配置文件，明确写出配置路径，例如：“把
config/logging.php中的channels数组加入'my_channel' => [...]”
版本兼容性不能只写“支持LTS”这种模糊表述
“Supports Laravel 9+”这种说法毫无意义——Laravel 9.0和9.51的事件系统差异很大，而composer.json里"laravel/framework": "^9.0"实际锁死的是9.0.x，不是整个9.x系列。
实操建议：
- 在“Compatibility”小节用表格或列表明确写出已验证的组合，例如：
php: ^8.1+laravel/framework: ^10.0 || ^11.0 - 如果某个功能仅在特定版本可用（如
IlluminateSupportStringable::afterLast()是10.26+新增），就在对应示例旁加注：// ≥ Laravel 10.26 - CI中跑测试的PHP/Laravel组合，就照搬过来写进README，别自己脑补
composer.json里的autoload和autoload-dev要和文档一致
文档说“通过MyPackageFoo::bar()调用”，但composer.json里"autoload": {"psr-4": {"App\": "src/"}}没配MyPackage\，用户按文档写就Class 'MyPackageFoo' not found。
实操建议：
- 检查
composer.json中autoload字段的命名空间前缀是否与文档中所有类引用完全一致（包括大小写） -
autoload-dev里的测试类路径，如果文档里写了“可运行vendor/bin/phpunit”，就得确保tests/目录被正确映射，否则Class 'TestsTestCase' not found - 发布前执行
composer dump-autoload -o并手动验证一次new MyPackageFoo()能否成功，别信“理论上应该可以”
最常被跳过的其实是版本号对齐：文档写的^2.5，而composer.json里"version": "2.4.9"，这种不一致会让composer show和Packagist页面显示混乱，用户连该装哪个版本都搞不清。
