CHFS：起一个HTTP文件服务，浏览器就能取件

它到底解决什么

CHFS，全名 CuteHttpFileServer，官网原话说得很直白：它是一个免费的、HTTP协议的文件共享服务器，用浏览器就能快速访问。这句话拆开看有两层意思：第一，它干的事是"共享一个目录"，不是"发送一个文件"；第二，接收这批文件的人不需要装任何东西，只要能打开浏览器就行。

传统的现场传文件手段各有各的卡点：U盘要插得上USB口、要没被安全策略禁用；网盘要能出外网、上传下载要等；自己搭个FTP或建站，对现场实施人员来说又太重。CHFS的思路是反过来的——不是把文件推给对方，而是在你自己的机器上开一个门，把一个目录"晾"在网络里，谁在同一网段、知道地址，用浏览器点开就能看、能下。官网把它和FTP、飞秋、网盘、自建站放在一起比较，给出的结论是"使用简单，适用场景更多"，尤其在个人使用和临时共享给别人这两类场景里比较顺手。

这跟本站已经讲过的 LocalSend 是完全不同的两条路子。LocalSend 是点对点：两台装了它的设备互相发现，一个发一个收，装完用完两边都不留痕迹，也不留端口。CHFS 是"起服务"：你在一台机器上开一个HTTP端口，这台机器就变成了一个临时的小型文件服务器，别人不需要装同款软件，甚至不需要装任何软件，浏览器地址栏敲个IP加端口就能进来。这个差别决定了两者的适用场景几乎不重叠，后面会专门展开讲。

展厅哪道工序会用到它

第一种，甲方电脑装不了软件，但浏览器能开。 不少甲方场馆、企业内网对终端管控很严，员工电脑、访客电脑不允许装第三方软件，U盘插上去也可能被安全策略直接拦掉。这种机器往往对浏览器没有类似的限制。这时候如果需要把一批素材、文档发给对方，装不了传输客户端就成了死结——而CHFS恰好不需要对方装东西，你在自己的笔记本上起一个服务，把地址发过去，对方开浏览器就能自己下载，不用求着甲方IT开权限装软件。

第二种，现场十几台设备要拿同一批素材。 布展现场常见的情况是：一批新素材要分发给七八台甚至十几台设备——工程机、讲解平板、触摸屏、临时接进来的笔记本。如果一台台用U盘或点对点工具传，一圈跑下来大半天没了。起一个CHFS服务，把这批文件挂在共享目录里，让这些设备各自打开浏览器去访问同一个地址自己下载，是并行的，比人肉一台台传快得多，尤其是当接收端设备数量比较多的时候，这个效率差距会很明显。

第三种，安卓一体机、播放盒子这类装不了传输软件的终端。 展厅里常见的安卓触控一体机、播放盒子，系统封闭、不开放安装权限，很多点对点传输工具压根装不上去。但这类设备基本都自带一个浏览器。只要它能连上同一个局域网，打开浏览器访问CHFS开的这个地址，就能把文件下载到本地存储里——这条路子对这类"没法装软件、只能用浏览器"的终端，几乎是唯一现实的现场传输手段。

怎么获取，该下哪个包

官网提供的下载入口只有两个：官网直链和百度网盘分流下载（提取码需要另外记）。这里要提醒一句：这是个体量不大的国产小众工具，没有在GitHub这类平台维护正式发布页，一旦官网直链或网盘链接哪天失效，没有现成的备用下载渠道——批量装机前建议先把安装包留存一份本地备份，别临到现场才发现下载不了。

CLI（命令行）程序是跨平台的，覆盖 Windows（x64/x86）、Linux（含常见的 386/amd64/arm/arm64 以及几种 MIPS 架构）、Mac（amd64）。展厅工程机以 Windows 为主，直接下对应位数的 Windows 包即可；如果现场设备是运行 Linux 的嵌入式播控盒子，需要先确认它的 CPU 架构再选对应的包，选错架构的包是运行不起来的。

GUI（图形界面）程序目前只有 Windows 版。这个GUI版本实际是作者另开的一个独立项目 chfsgui，性质是"给CLI核心程序套一层图形外壳"，方便不熟悉命令行的人操作。这个GUI外壳项目本身在GitHub上公开，按 LGPL-3.0 协议开源；但它包裹的核心文件服务程序（也就是CHFS本体）并不在这个开源仓库里，源码和许可证情况要分开看，不能因为外壳开源就认为CHFS核心也是开源的。

授权情况这里要交代清楚：官网全站没有任何许可证条款、使用条款或EULA页面，只用"免费的"三个字概括。核心程序不提供源码，只发布编译好的二进制。这意味着商用是否被允许、是否可以在企业项目里长期使用、有没有分发限制，官方都没有明确说明——本篇没有查到任何相关条款，如实告知：这块信息目前是空白，不是被漏掉，是官方确实没写。如果项目上对软件合规性有明确要求（比如甲方IT审计要看许可证清单），建议要么找作者本人书面确认使用范围，要么换成本站已收录的、许可证条款写得清楚的方案（比如 LocalSend，Apache-2.0）。日常展厅现场调试用，这个空白影响不大；但涉及甲方合规审查的项目，这条边界要提前跟项目负责人说清楚。

最短可用路径

Windows 现场最常用的是 GUI 版本，解压后直接双击运行，界面上选好要共享的目录、填好端口，点启动就行，图形界面比记命令行参数省心。

用 CLI 版本的话，解压出来的可执行文件不需要安装，直接运行。核心用得上的三个参数是：-path 指定要共享的目录（默认是程序所在目录本身，要共享多个目录用竖线|分隔，路径里带空格必须用引号包住）；-port 指定监听端口（默认是80，现场常见做法是换成一个不常用的端口比如8080，避免和机器上已经在跑的其他服务撞车）；-file 指定一份配置文件，走配置文件能设置命令行参数覆盖不了的东西，比如账户权限、HTTPS证书、页面自定义这些，命令行本身没有对应的开关。

启动之后，同一网段内的设备打开浏览器，访问这台机器的局域网IP加端口号（比如 http://192.168.1.20:8080），就能看到共享目录里的文件列表，点文件直接下载。官网提到支持扫码下载，方便手机端直接扫码打开这个地址，不用手动敲IP。

Windows 上还有个提效小技巧：官网提供了一份注册表模板文件，导入后可以在文件资源管理器里右键任意目录，快捷调出共享操作，不用每次都手动敲路径参数，适合现场需要频繁换目录共享的情况。

展厅工程里真正要弄明白的那几件事

"起服务"和"传文件"，思维完全不是一回事

理解这条差异，是用好这个工具的前提。LocalSend 那类点对点工具，做的是"这一次、这几台设备之间"的临时对传：两台设备互相发现，点一下就传，传完就结束，没有谁在后台持续监听什么。CHFS 不一样，它在你的机器上开出一个持续存在的HTTP端口——只要这个进程没关，这个端口就一直在那儿监听，同一网段里任何知道地址（甚至不需要知道，扫一下这台机器的IP加常见端口就能碰到）的设备都可能连上来。

这不是缺点，这是它的工作原理决定的必然结果，也正因为如此，CHFS 天然比点对点工具多一层需要现场把关的东西：安全边界。

安全边界——本篇最该记住的一节

在甲方内网里随手起一个HTTP共享服务，如果不管它共享的是什么目录、开没开权限限制，是实实在在的安全事故风险，不是危言耸听。具体拆成三条讲：

共享目录的范围要收窄，不要图省事整盘共享。 参考官方提供的配置文件样例（chfs.ini），目录下载策略这一项默认值是"不限制"——也就是说，如果不特意去改这项设置，共享目录不只是能一个个文件点开看，而是可以被整个打包下载走。如果为了图省事，直接把一个很大的目录甚至整个盘符扔给共享路径，等于把这一整块内容变成了任何连得上这个端口的人都能一键打包带走的东西。展厅项目里常见的甲方资料、内部文档、客户信息，一旦和要分享的素材混在同一个目录里，风险就是这么来的。正确做法是：新建一个专门存放本次要分享内容的干净目录，只把这个目录挂上去，用完删掉或者干脆不留。

默认没有密码，谁都能进来看。 同样参考官方配置文件，账户和权限规则是一段可以选择性追加的配置区块——如果启动时没有单独配置账户，就没有密码校验、也没有按目录设置的读写限制，同一网段里能连上这个端口的人都可以直接以访客身份看到共享的内容。需要限制访问范围时，要么在配置文件里配一个账户区块（设密码、按子目录分别设"不可访问/只读/可写/完全控制"这几档权限），要么用配置文件里的IP地址过滤功能把能连进来的设备限定在一个范围内。这两项都得走配置文件，不是命令行参数能直接设的。

如果给了写权限，对方能改能删。 配置文件里的账户权限规则不只有"只读"，还有"可写"和"完全控制"两档。一旦给某个账户配了写权限，对方不仅能拿走文件，还能往里传新文件、甚至删除已有文件。官方给的默认删除策略是移动到系统回收站（不是所有系统都支持，用前建议先测一下），但如果这项被改成"真正删除"模式，删掉的东西就是真的没了。现场如果没有明确需要对方往里写文件的场景，就不要开写权限，只给只读。

综合起来，展厅现场用它的正确姿势是：只共享真正该共享的那个干净目录，能设密码就设，用完立刻把进程关掉，不要让它常驻。开工前跟甲方IT提前打个招呼——"现场会临时起一个HTTP文件服务，用完就关"，比事后被网络监控发现、自己说不清楚，要主动得多，这句话本身也能直接写进现场作业交底里。

它不是长期方案

CHFS 解决的是调试期、交付前这段时间的临时取件需求。它没有排期、没有分组推送、没有失败重试和状态回执，全靠人现场手动开关。项目交付之后，如果客户长期需要接收更新内容，不应该继续靠这种临时服务撑着，该走正经的内容分发方案。

踩坑与排错清单

什么时候别用它

只是两台设备临时对传，不想留一个持续监听的端口。 这类场景用点对点工具更合适，装完即用，用完两边都不留痕迹，不用管端口和防火墙这些额外的事。

甲方内网对新增服务端口有严格审批、现场来不及报备。 AP隔离、防火墙策略这些技术上都有解法，但前提是甲方IT配合。没批下来之前自己现场起服务，是流程问题，不是技术问题，得先谈流程。

长期、正式的内容分发和多设备管理需求。 它没有排期、分组下发、失败重试和状态回执，硬拿它撑长期运维，只会让本该自动化的事变成体力活。

对断点续传或传输一致性校验有硬性要求的大文件搬运。 官网的功能介绍里没有提到这项能力，没查到相关说明，追求这类保障的场景应该找专门带这项能力的传输工具。

与本站的衔接

先判断这次的需求到底是"点对点对传"还是"起服务给一堆人取"——如果是前者，看 LocalSend 软件页，两者常常在同一个项目里分别派上用场：装不了软件的设备用CHFS开个浏览器就能取，能装软件的设备之间互传用LocalSend更省心。

判断设备互相连不上是不是网络策略卡住的，比如两台设备明明在同一现场却互相访问不到，先看本站《展厅设备组网 IP 怎么规划》，里面把子网划分、网段隔离这些概念讲得更细。

需要远程接管展厅工程机做维护，跟本文讲的"临时开个服务发文件"是两码事，可以看 RustDesk 软件页——常见配套用法是先用RustDesk连上机器排查，发现素材缺了或者过时了，再考虑要不要现场起一个CHFS临时补传。

交付之后，这些环节谁来管

临时用的工具解决的是当下的问题。展厅要跑好几年，中间会换人、换素材、换设备——那时候靠的不是工具好不好用，是有没有一套能交接的运行方式。

企服君把设备纳管、状态监控、批量操作做成标准能力，让运维不依赖具体是谁在做。见集成商年费方案。

出处

本文所述的功能列表、命令行参数、配置文件字段（账户权限、目录下载策略、删除模式等）与下载渠道，均来自CHFS官方渠道：官网首页（含下载、基本用法、高级用法各节）、官方发布的配置文件样例 chfs.ini、Docker Hub 上标注的官方镜像页面，以及作者在GitHub上开源的GUI外壳项目 chfsgui 的仓库信息与README。具体地址见本页出处栏。功能细节可能随版本调整，以官方页面为准；许可证与商用条款方面，本文已如实注明官网未作声明的部分，不做主观推断。