Portless 本地命名路由
理解 Portless：稳定的本地网址，不代表端口消失
理解 Portless 如何为开发应用命名、后端端口仍承担什么职责，以及本地 HTTPS、分支名称和公网分享为何需要分别决策。
你将学会
- 稳定的是名称，端口不再是使用入口
- 有意识地选择开发身份
- 区分三种不同的证据
开始前需要
- 了解 HTTP 访问源、端口和命令行基础
- 能够区分回环、局域网与公网暴露
追踪命名请求，明确安装权限边界，并区分已观察行为和未测试集成。
先看结论
- 稳定名称对使用者隐藏端口分配，但不会消灭端口。
- 工作树主机名不等于应用资源已经全面隔离。
- 本地路由、证书信任和远程暴露是不同边界。
稳定的是名称，端口不再是使用入口
Portless 可以给开发应用提供 https://shop.localhost 这样的可读地址。本地代理接收浏览器请求，查找主机名，再转发至回环地址上的应用端口。端口仍然存在；改变的是人、浏览器书签和开发 Agent 可以使用应用名称，不必记住本次启动恰好空闲的数字。
例如前端和 API 都默认监听 3000。修改其中一个端口能解决当前冲突，却可能让回调地址或复制给同事的测试说明失效。命名路由把人使用的身份与进程端口分配分开，但不会自动重写应用配置、放宽 CORS 权限，也不会替你向外部服务登记 OAuth 回调。
有意识地选择开发身份
文档中的启动器会在 4000–4999 范围分配可用应用端口。第一次实验适合明确指定名称；多个检出目录同时运行时，名称推断和关联工作树的分支前缀更方便。分支前缀是一种路由身份，不能证明这些工作树之间的 Cookie、数据库和凭据也已经隔离。
固定版本的包元数据显示版本为 0.15.6，要求 Node.js 24 或以上，使用 Apache-2.0 许可。CLI 默认使用 HTTPS，涉及本地证书生成和信任配置；代理也支持在指定端口提供 HTTP。这两种模式的浏览器行为和安装权限不同，不能承诺所有机器都能零配置运行。
区分三种不同的证据
本系列依据固定提交中的源码，而不只是会继续变化的 README。有界实验在不修改行为的前提下转译所检查的代理模块，使用两个临时回环后端，通过了 24 项 HTTP/1.1 案例。案例覆盖路由、转发头和内部 hosts 同步授权，但没有真正修改操作系统 hosts 文件。
实验没有安装 CLI、信任证书、开放公网隧道、执行 HTTP/2 或验证框架热更新。它们属于有文档依据、仍需集成验证的功能。首次成功条件应更具体：预期名称到达预期应用，未知名称失败，并且停止应用后的行为能够解释，而不是一次请求成功就宣布全部部署完成。
实施步骤
- 1
记录一个应用名称及其预期后端。
- 2
确认 Node.js 兼容性并明确选择 HTTP 或 HTTPS。
- 3
检查活动路由，再访问命名网址。
- 4
分别记录尚未验证的浏览器、框架和分享功能。
可复制示例
{
"示例性质": "概念路由，不是配置文件",
"浏览器源": "https://shop.localhost",
"路由名称": "shop.localhost",
"后端": "127.0.0.1:<分配的端口>",
"端口仍然存在": true
}常见问题
Portless 是生产托管平台吗？
它的文档主要描述本地开发路由。本次测试没有认证它适合作为生产入口，也没有提供生产环境部署方案。
稳定名称会自动解决 CORS 吗？
不会。CORS、Cookie 和回调允许名单属于应用与外部服务配置。改变访问源后，仍可能需要明确更新这些设置。
资料来源
- README.md来源核查 2026-09-08
- packages/portless/package.json来源核查 2026-09-08
- LICENSE来源核查 2026-09-08
- packages/portless/src/proxy.ts来源核查 2026-09-08