中小团队优先用devpi，5人以下或临时验证用pypiserver；devpi支持按需缓存、多级索引、权限管理与web ui，启动即用，无需同步全量pypi，且默认监听http://0.0.0.0:3141。
直接说结论：中小团队优先用 devpi，5人以下或临时验证用 pypiserver；别一上来就折腾 Artifactory 或自建 Warehouse。
devpi 为什么是中小团队的默认选择
它不是“另一个镜像工具”，而是带权限、缓存、索引分层和上传能力的一体化服务。你不需要手动同步全量 PyPI，devpi 默认启用「按需缓存」：第一次 pip install requests 会自动从官方源拉取并存本地，后续请求直接走内网，速度提升 5–10 倍。
- 启动后默认监听
http://0.0.0.0:3141，访问即看到 Web UI，无需额外 Nginx -
devpi use+devpi login后，devpi upload可直接推包，不依赖twine或.pypirc - 支持多级索引（比如
root/pypi缓存官方源，root/dev专供内部包），避免命名冲突 - 关键但常被忽略：
devpi-server的数据目录（默认~/.devpi/server）必须定期备份，删错就丢全部缓存+私有包
pypiserver 适合什么场景
当你只需要一个“能 pip install 就行”的轻量级端点，比如 CI 构建机临时拉包、测试环境快速验证、或给非 Python 同事提供一个可上传的简易接口。
- 启动命令里带
-P . -a .表示禁用认证——这在内网可用，但千万别暴露到公网 - 必须加
--fallback-url https://pypi.tuna.tsinghua.edu.cn/simple/，否则遇到没上传的包会直接报错，而不是自动回退下载 - 上传依赖
twine，且必须配好~/.pypirc；常见错误是repository地址末尾漏了/simple/，导致 404 - 它不管理用户权限，所有上传者共用同一套凭证，多人协作时容易覆盖同名包
pip 客户端配置最容易踩的三个坑
无论用哪个服务，客户端连不上，90% 是因为这三件事没做对。
-
pip config set global.index-url必须带协议、端口、路径三段，例如http://192.168.1.100:3141/root/pypi/+simple/——少一个/或写成/simple（缺末尾斜杠）都会失败 -
pip config set global.trusted-host 192.168.1.100必须显式添加，否则 pip 会因 HTTPS 跳转或 HTTP 不安全警告而中止 - 如果公司用了代理，
pip会优先走系统代理，导致请求发到外网；加--trusted-host参数无效，得在配置里设global.proxy或临时用export HTTP_PROXY=
上传私有包时版本和命名的实际约束
不是所有合法的 Python 包名都能被仓库接受，尤其当混用 devpi 和 pypiserver 时。
-
devpi对包名校验更严：不允许下划线_，只认连字符-；my_tool会被拒绝，必须改名成my-tool -
pypiserver允许_，但pip install my_tool实际仍会去找my-tool——这是 pip 自身行为，不是仓库问题 - 版本号含
dev、rc等预发布标识时，devpi默认允许，pypiserver需确认是否启用了--hash-algo校验，否则可能跳过完整性检查 - 上传前务必运行
python -m build，别直接传setup.py；devpi upload只认dist/*.whl和dist/*.tar.gz
真正难的不是搭起来，而是让所有人用对、用稳。比如 devpi 的索引层级一旦设错，开发人员 pip install 时可能误装了测试分支的包；又比如 pypiserver 没配 --fallback-url，CI 流水线就会卡死。这些细节不写进 SOP，迟早出问题。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
