Portless 本地命名路由
Portless 性能与成本：代理开销和开发便利要分开测
围绕等价协议、后端工作量、路由规模与浏览器行为设计真实评估，不虚构延迟或节省比例。
你将学会
- 可读网址不是延迟基准
- 比较等价路径，并保留失败
- 把维护和分享成本也记下来
开始前需要
- 了解 HTTP 访问源、端口和命令行基础
- 能够区分回环、局域网与公网暴露
追踪命名请求，明确安装权限边界，并区分已观察行为和未测试集成。
先看结论
- 开发便利与请求延迟是不同结果。
- 线性匹配只是分析假设，不是瓶颈证明。
- 功能测试通过不能证明吞吐或费用节省。
可读网址不是延迟基准
Portless 可能减少记忆端口和更新本地引用的人力工作，这种便利与请求吞吐或应用启动耗时不同。代理增加连接路径，还可能承担 TLS 与协议适配；开销大小取决于负载、运行时和浏览器，不取决于网址是否友好。因此需要分别说明评价的是机器性能，还是开发过程中的认知负担。
源码通过多轮线性 Array.find 匹配路由，每次请求都调用 getRoutes。这支持“路由数量和回调工作可能影响查找成本”的假设，却不能证明它是实际瓶颈。返回内存数组的调用方与读取状态的调用方成本不同；提出缓存前，应先分析真实集成，否则可能引入路由变更不可见的问题。
比较等价路径，并保留失败
合理实验固定应用版本、响应大小、机器和运行时，在受控连接复用与并发条件下比较直连和代理请求。把预热请求与启动、证书配置分开，报告延迟分布和错误数，而不是最快的一次请求。保留原始测量，以免重试在统计中悄悄抹掉失败。
HTTP/2 多路复用是浏览器一侧的独立能力，不是整个应用变快的证据。尽可能比较相同协议，再单独评估目标 HTTPS 与热更新流程。微小 JSON 响应的基准不能替代包含流式输出、资源加载和 WebSocket 重连的框架页面。本次 24 项功能案例有意不提供性能结论。
把维护和分享成本也记下来
处理信任、版本冲突、过期路由和启动服务的时间，也属于采用成本。可选分享依赖外部工具，有独立访问政策和可能的收费。本地软件许可不能说明这些服务的价格，本文也不引用未验证的订阅费用；选择分享之前，应再核对实际服务条件。
从未知值为 null 的测量表开始，将开发者被打断的时间与 CPU、内存、请求延迟和失败率分开记录。如果稳定网址确实为团队节省时间，应展示观察到的前后任务及局限；不要把源码清单或冒烟测试成功转换成虚构的百分比提升。
实施步骤
- 1
固定后端、运行时、协议和响应内容。
- 2
比较预热直连与代理请求，保留失败记录。
- 3
单独评估启动、证书和热更新。
- 4
公开实际观察，未测节省保持未知。
可复制示例
{
"基准状态": "方案，尚未执行",
"路由数量": null,
"直连P95毫秒": null,
"代理P95毫秒": null,
"错误数量": null,
"节省开发分钟": null,
"外部分享费用": null
}常见问题
HTTP/2 一定降低页面加载时间吗？
不一定。应用工作、连接复用、资源与协议适配都会影响结果，需要测量实际目标浏览器流程。
24 项案例可以宣传为性能基准吗？
不可以。它们用测试服务器验证部分行为，没有记录比较延迟、吞吐或成本。
资料来源
- packages/portless/src/proxy.ts来源核查 2026-09-08
- packages/portless/src/types.ts来源核查 2026-09-08
- README.md来源核查 2026-09-08