"远程查看本地文档"听起来像是一个网盘就能解决的事，但真正落到日常开发场景里，需求往往比想象中具体：文件散落在多台 Windows 机器上，有些目录不能上公网云盘，有些文档只需要"看一眼"而不是完整协作，手机或临时设备打开浏览器就能用最好。公有网盘同步大目录时上行带宽吃紧，远程桌面又把整台主机暴露在风险面里。于是问题变成：能不能用尽可能少的组件，在本地搭一条只读优先、按需写、浏览器直达的文件访问链路。
下面是我近期的一次技术选型与落地复盘，重点放在架构决策和边界条件，而不是某个具体产品的功能罗列。
先拆链路：远程查看本地文档需要解决什么
一条可用的远程文档查看链路至少包含四个层次：
服务层：本地需要一个能通过 HTTP 暴露目录、支持基础鉴权和在线预览的轻量服务。传统做法是 IIS 或 Apache 加目录浏览模块，但配置成本和攻击面都偏高。更轻的路径是用单文件或低依赖的 Web 文件管理器，例如 Tiny File Manager 只需要 PHP 5.5+，两个文件即可启动，支持多用户登录和上传下载。PHP 内置服务器或 Nginx + PHP-FPM 的组合也能做到，但对于"只是想远程看一眼文档"的场景，集成度越高的方案维护负担越小。
穿透层：本地服务跑在 NAT 后面，外网无法直接寻址。反向代理隧道（frp）和虚拟组网（ZeroTier、Tailscale）是两条主流路线。frp 需要一台有公网 IP 的 VPS 做 frps 中转，客户端主动建立长连接，HTTP/HTTPS 代理按域名路由，配置可控但运维责任在自己。ZeroTier 走 UDP 打洞，成功时延迟低，但在国内对称 NAT 和跨运营商场景下 P2P 成功率不稳定，不配置 Moon 节点时跨网速度可能明显下降。如果不想维护 VPS，ZeroTier 更适合"设备对设备"的点对点查看；如果追求稳定域名入口和 HTTPS 终结，frp + Nginx 的确定性更强。
安全层：这是最容易被"跑通就行"心态跳过的一层。远程查看本地文档意味着目录内容可被外部读取，鉴权、传输加密和权限收敛必须同时在位。
预览层：浏览器端对 PDF、图片和主流视频格式的原生支持已经足够，不需要额外转码服务。服务端只需要正确设置 Content-Type 和 Content-Disposition，避免文件被强制下载或错误渲染。
穿透方案的取舍：frp 还是 ZeroTier
这两条路线没有绝对优劣，取决于你是否愿意维护一台公网入口。
frp 的核心优势是确定性。服务端跑在 VPS 上，客户端配置 type = http 或 https，配合 custom_domains 将域名路由到内网服务端口。Nginx 在前面做 TLS 终结和访问日志，出问题时有明确的排查节点。代价是需要一台 VPS，并且 frps 的 token 认证和 TLS 配置需要自己负责，不能依赖默认值。
ZeroTier 的优势是零公网入口。设备加入同一个 Network ID 后获得虚拟 IP，浏览器直接访问虚拟 IP 上的服务端口，不经过任何端口映射。对于"手机临时看一眼家里电脑上的 PDF"这种低频场景，它省掉了 VPS 成本和域名备案。但国内环境的 UDP QoS 和 NAT 类型会直接影响体验，如果两端不在同一运营商或遇到对称 NAT，打洞失败后回落到官方中继，延迟和带宽都不可控。我的做法是：固定入口用 frp，临时设备用 ZeroTier 兜底，两者不互斥。
实现链路中的几个关键配置
服务端的选择上，我倾向于"零外部依赖"的绿色程序。对比了多个同类工具后，最终落地时用的是 80KM 私有网盘 ，它的运行形态符合这条链路对服务层的要求：解压后直接启动，不依赖数据库和 IIS，内存占用低，管理端可以给不同用户绑定各自的本地目录并分配只读或读写权限。从技术视角看，它把 PHP 运行时、HTTP 服务和权限模型打包成了一个可双击运行的单元，省掉了单独维护 Web 服务器和 PHP-FPM 的环节。对于一台兼做其他用途的 Windows 主机来说，这种"低侵入"比功能丰富更重要------不需要的时候删掉目录即可，不污染系统环境。
穿透侧我选择的是 frp + Nginx 的组合。frpc 将本地服务端口映射到 VPS，Nginx 按域名做反向代理并加载证书。这里有一个容易忽略的细节：frp 的 HTTP 代理本身不终结 TLS，如果在 frpc 中配置 type = https 并直接传入证书，证书管理会分散在客户端；更干净的做法是 frpc 用 type = http，由 Nginx 在服务端完成 TLS 终结和 HSTS 下发。这样证书续期和访问日志都集中在一个位置。
预览方面，PDF 和图片基本靠浏览器原生能力即可。视频需要注意 Content-Type 的正确性：MP4 应返回 video/mp4，MKV 在部分浏览器中不被原生支持，如果服务端没有转码能力，至少要让用户明确知道"需要下载后播放"，而不是返回一个空白页面。
安全边界：远程查看本地文档真正容易出事的地方
第一，默认凭据必须清除。很多轻量文件服务首次启动会生成默认管理员账户，例如 Tiny File Manager 的默认账户是 admin/admin@123 和 user/12345。如果穿透链路先于密码修改被扫到，目录就等于公开。部署顺序应当是：本地改密 → 本地验证鉴权 → 再配置穿透。
第二，分享链接的最小化。带密码和有效期的临时链接，比长期可访问的目录入口安全得多。如果服务本身支持这一能力，优先用它替代"把整个目录挂到公网"。有效期不是形式主义，过期自动失效能显著降低链接泄露后的窗口期。
第三，传输层不能省。纯 HTTP 在局域网内可以接受，一旦经过穿透层就必须上 TLS。Nginx 反代加 Let's Encrypt 是成本最低的路径；如果走 ZeroTier，虚拟网络本身有加密，但浏览器到服务之间仍然是 HTTP，敏感场景下建议在本地也启用 HTTPS 或限制虚拟网络的成员审批。
第四，权限按人收敛，不按目录收敛。多用户场景下，只读权限应该绑定到具体账户，而不是靠"大家都很自觉"。服务层如果支持独立的读写/只读角色，就在创建账户时直接限定，不要给所有人同一个高权限账号。
这条链路的适用边界
它适合的是低频、按需、以查看为主的远程文档访问：出差时调取一份 PDF、临时把一段视频发给客户、在手机上翻一下家里的资料目录。它不适合高频并发写入、版本协作或大规模文件分发------那些场景需要的是真正的文档管理系统或对象存储，而不是一条轻量 Web 链路。另外，Windows 版本兼容性要以实际程序的说明为准，老系统上部署前先确认运行时依赖，避免在 XP 或早期 Server 上浪费时间。
从工程角度看，"远程查看本地文档"的难点不在某一步配置，而在于把服务、穿透、安全和预览四层收敛到可维护的最小范围。链路越短，排查路径越清晰；默认值越少，出事概率越低。