Portless 本地命名路由
Portless 学习实践：设计只读的路由与访问源解释器
提出一个教学工具方案，解释匹配优先级、浏览器访问源和暴露范围，不偷偷配置证书或分享应用。
你将学会
- 让不可见的路由决策可见
- 把观察与修改分开
- 把源码实验变成回归规范
开始前需要
- 了解 HTTP 访问源、端口和命令行基础
- 能够区分回环、局域网与公网暴露
追踪命名请求，明确安装权限边界，并区分已观察行为和未测试集成。
先看结论
- 解释器应以模拟数据展示真实匹配层级。
- 只读可视化不能掩盖系统配置操作。
- 评价学习理解，不评价动画复杂程度。
让不可见的路由决策可见
有价值的扩展可以让学习者输入模拟 Host，逐步观察固定版本的匹配层级：原始访问主机、规范化结果、精确名称候选、tailnet 访问主机候选和可选通配回退。高亮最终第一条路由，并解释为何后面更具体的后缀没有胜出。这是教学界面设想，不是 Portless 已交付的功能。
默认使用模拟路由与端口。不能只为了让图动起来，就发现私人应用名称、读取真实令牌或连接用户输入的主机。二维 SVG 流程配合可访问的有序文字说明，已经足够表达这种关系；Three.js 会增加渲染和交互工作，却不天然让四层优先级链更清晰。
把观察与修改分开
第二个视图可以比较 HTTP、HTTPS、代理端口变化和工作树名称下的浏览器访问源。它应说明协议、主机名和端口都重要，同时提醒 Cookie 范围与外部服务允许名单还有独立规则。仅仅显示两个网址不同，不能宣称已经验证 CORS 或 OAuth 配置。
将来若增加真实路由导入，必须明确由用户选择，仅本地、只读，并在导出前隐去敏感名称。不要把信任证书、强制替换、安装服务或公网分享按钮放进看似无害的可视化工具。这些动作需要单独授权和清楚后果；教学图不是扩大操作权限的理由。
把源码实验变成回归规范
现有 24 项案例可为解释器提供预期结果，包括严格拒绝、精确名称优先和首个后缀选择。保留明确版本选择，避免上游行为改变后课程悄悄失效。解析或显示出错时，应显示错误，而不是补出看似合理的虚构路由；否则工具反而会教会用户错误模型。
下一步实现里程碑可以是支持键盘、完整本地化标签和测试数据检查的可访问静态原型，然后观察学习者能否预测陌生路由、区分本地与公网暴露。本文未交付交互解释器、三维动画或用户研究；配套 SVG 展示方案，已有实验则说明其证据边界。
实施步骤
- 1
依据固定实验定义模拟路由和预期结果。
- 2
先做支持键盘阅读的二维说明，再考虑动画。
- 3
真实状态导入保持可选，导出先脱敏。
- 4
测试预测任务，分清设想与已交付行为。
可复制示例
{
"方案": "只读路由解释器",
"状态": "尚未实现",
"输入": "模拟Host和路由表",
"网络请求": false,
"读取机器令牌": false,
"修改证书或服务": false,
"学习检验": "预测路由并解释暴露范围"
}常见问题
Portless 已经包含这个解释器吗？
没有。这是根据固定源码和测试结果提出的编辑部实践方案，不是对现有产品界面的描述。
为什么不立即使用 Three.js？
关键关系是有顺序的路由判断。可访问二维图能以更低复杂度表达它；只有证明能改善学习时才值得加入三维。
资料来源
- packages/portless/src/proxy.ts来源核查 2026-09-08
- packages/portless/src/types.ts来源核查 2026-09-08
- README.md来源核查 2026-09-08