直接编辑项目根目录下的 composer.json 中小写 description 字段，值为 UTF-8 编码字符串，改完无需执行命令，但需手动触发 Packagist 同步或重装依赖才能生效。
composer.json 里 description 字段怎么改
直接编辑项目根目录下的 composer.json，找到 description 字段，改掉就行。它只是纯文本字段，不参与安装、加载或版本解析，改完不用执行任何命令生效——但别人看 packagist.org 或运行 composer show 时才会反映出来。
常见错误现象：composer require xxx 后发现新包没显示描述；或者自己发包到 Packagist，页面上 description 是空的——大概率是本地 composer.json 根本没写这个字段，或拼错了（比如写成 desc 或 DESCRIPTION）。
- 字段名必须是小写的
description，大小写敏感 - 值必须是字符串，不能是
null、false或空数组 - 如果用
composer init初始化过，它会交互式问你描述，但默认可能留空，得手动补上 - 中文描述完全没问题，但注意 JSON 文件编码要是 UTF-8，别用记事本另存为 ANSI 导致乱码
修改后怎么让 Packagist 页面更新
Packagist 不自动轮询你的仓库，它只在你触发同步时拉取最新 composer.json。改完本地 description，必须让 Packagist 重新抓取一次。
使用场景：你维护一个开源包，刚发了 v1.2.0，顺手更新了 description，但官网页面还是旧的。
- 登录 packagist.org，进你的包页面，点右上角
Update按钮（需有包维护权限） - 或者用 GitHub/GitLab 的 webhook 自动触发：确保仓库设置里已启用 Packagist webhook，且推送的是 default branch（通常是
main或master） - 手动触发失败？检查 Git 提交是否真包含了修改后的
composer.json—— 有时候git add -u漏掉了它
description 写什么才算有用
它不是 slogan，也不是 README 替代品，而是让别人在搜索、列表浏览时 3 秒内判断“这东西是不是我要的”。太笼统（如“一个 PHP 工具库”）或太技术（如“基于 PSR-14 实现的事件分发器”）都降低识别效率。
性能 / 兼容性影响：无。这个字段不参与任何运行时逻辑，也不会被 Composer 加载或解析。
- 优先说明解决什么问题：比如
"Adds Laravel-style request validation to Slim 4" - 避免形容词堆砌：“高性能、轻量、优雅”之类毫无信息量
- 如果包有明确目标框架/标准，可以提：比如
"PSR-18 HTTP client wrapper with retry and circuit breaker" - 长度控制在 120 字符内，Packagist 列表页会截断显示
为什么 composer show 不显示新 description
composer show 默认查的是已安装包的元数据，而本地改的 composer.json 只影响当前项目定义，不影响已安装依赖的描述。如果你改的是自己项目的 description，那 composer show myvendor/myproject 才能看见；如果改的是某个依赖包的 composer.json，那根本不会生效——你改的不是它的源码仓库。
容易踩的坑：误以为改了 vendor 里某个包的 composer.json 就能影响 composer show 输出。其实 vendor 下的文件是只读快照，Composer 不会从那里读取描述，而是从其原始 source（Packagist 或 VCS）拉取。
- 确认你在改哪个
composer.json：项目根目录下的是“你自己这个包”的描述；vendor/xxx/yyy/composer.json 是别人包的副本，改了白改 -
composer show不加参数时列出所有已安装包，但描述来自 Packagist 缓存，不是本地 vendor 文件 - 想立刻验证？删掉
vendor和composer.lock，再composer install—— 这样会重新从源拉取元数据
最常被忽略的一点：description 字段只对“作为 package 被发布”的项目有意义。如果你的项目 never 发布、never require 被他人引用，那它本质上就是个私有脚本，填不填 description 完全无所谓。
