能被别人 composer require 安装的包必须满足三要素：packagist 四项必填字段（name、type、autoload、license）全合规；psr-4 命名空间、目录结构、类名严格一致并执行 composer dump-autoload -o；git 打带 v 前缀的语义化标签（如 v1.0.0）且推送至远程，首次提交后须在 packagist 页面手动点击 update 按钮同步。
能发布、能被别人 composer require 安装的包，不是写完 PHP 类就完事了——它必须满足 Packagist 的元数据规范、Git 标签规则和 PSR-4 加载契约。漏掉任意一环，别人装不上，或者装上了却 Class not found。
composer.json 必填字段怎么设才不被 Packagist 拒绝
Packagist 不会接受一个“看起来像包”的项目，它只认四个硬性字段：name、type、autoload、license。其中 name 和 autoload 最容易出错。
-
name必须是小写vendor/name格式（如myorg/my-utils），且vendor部分要和你在 Packagist 注册的用户名完全一致；含大写字母、下划线或点号都会导致提交失败 -
type显式写成"library"，别留空或填project——Packagist 会直接跳过非library类型 -
autoload至少配psr-4，键必须是完整命名空间加双反斜杠（如"MyOrg\MyUtils\": "src/"），值必须是真实存在的相对路径；末尾多一个/或少一个\都会导致类加载失败 -
license字段不能空，MIT、Apache-2.0、GPL-3.0 等 SPDX ID 均可，但必须写全（如"MIT"，不能写"mit"或"mit license"）
PSR-4 映射为什么总报 Class not found
不是命名空间写错了，就是目录结构没对齐。PSR-4 是严格字符串匹配，大小写、斜杠、文件名三者缺一不可。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 假设
composer.json中写了"MyOrg\MyUtils\": "src/"，那src/下必须存在MyOrg/MyUtils/目录结构，不能是src/myorg/myutils/（Linux 下大小写敏感，Windows 下可能缓存旧路径） - 类文件名必须和类名一致，比如
class Calculator必须放在Calculator.php里，不能叫calc.php或calculator.php - 改完
composer.json后，必须运行composer dump-autoload，否则新映射不会生效；本地测试时建议加-o参数生成优化加载器：composer dump-autoload -o - 别把
tests/或bin/目录塞进autoload.psr-4——它们该进autoload-dev，否则上线项目会无故加载测试代码
Git tag 怎么打才能让别人 require 到正式版本
Packagist 不看 composer.json 里的 version 字段，它只解析 Git tag。没 tag，就没有版本；tag 格式错，就等于没发。
- 必须用语义化版本带
v前缀：运行git tag v1.0.0，不是git tag 1.0.0；v1.0、dev-main、feature/foo都不算有效版本 - tag 必须推送到远程：
git push origin v1.0.0或批量推送所有 tag：git push origin --tags；只本地打 tag，Packagist 根本看不到 - 首次提交到 Packagist 后，页面会显示 “This package is not auto-updated”；必须手动点右上角
Update按钮，才会拉取已推送的 tag - 如果改了代码又想重发同版本，先删远程 tag：
git push origin :v1.0.0，再删本地：git tag -d v1.0.0，最后重新打 + 推
私有包怎么让自己的项目装得上
私有包不会出现在 Packagist，所以使用方项目必须显式告诉 Composer：“去哪找这个包”。靠的是 repositories 字段，不是改包自己的 composer.json。
- 在使用方项目的根级
composer.json中添加："repositories": [{"type": "vcs", "url": "https://gitlab.internal/myorg/my-logger"}]；type用vcs，别用package（维护成本高、易出错） - Git 仓库需认证时，凭据不能写进
composer.json，应走auth.json文件，且权限必须是600（chmod 600 ~/.composer/auth.json） - 私有包也必须打合法 tag（
v1.0.0），否则composer require myorg/my-logger默认只会拉dev-main分支，不稳定也不可重现 - 本地开发调试时，可用 path 仓库方式快速验证：
{"type": "path", "url": "../my-logger"}，但上线前务必切回vcs方式
最常被忽略的一点：Packagist 页面首次提交后，你看到的不是“已发布”，而是“未自动更新”。不点那个 Update 按钮，哪怕 tag 已推、仓库公开、配置全对，别人也 require 不到任何东西。
