最近看到一个很有意思的项目：OpenFreeMap。
它做的事情很直接：让你在网站或 App 里免费使用基于 OpenStreetMap 的自定义地图。可以用它的公共实例，也可以自己部署。项目本身开源，而且作者明确说不是 open-core，生产环境配置也在仓库里。
这点我挺喜欢。
很多地图相关服务说自己“开放”，最后一看，SDK 开放，数据收费；样式开放，瓦片收费；开发环境免费，流量上来以后账单吓人。OpenFreeMap 的思路更朴素：地图瓦片本质上是文件，那就尽量把它做成可分发、可缓存、可自托管的文件服务。
地图服务最贵的地方，很多时候不是地图本身，而是托管和流量的不确定性。
OpenFreeMap 是什么
OpenFreeMap 是一个免费、开源的地图托管方案，数据来自 OpenStreetMap，样式兼容 MapLibre 生态。
它提供免费公共实例，也提供 Positron、Bright、Liberty、Dark、Fiord 这些默认地图样式。Liberty 配合倾斜视角还能看到 3D 建筑效果。更关键的是，它还放出了每周更新的全球瓦片下载，格式包括 Btrfs 和 MBTiles，自托管脚本、样式项目 openfreemap-styles 也都能直接看。
官网说公共实例没有请求次数限制，不需要注册，没有 API Key，也没有 cookies。成本主要靠捐赠覆盖。
这对小项目很友好，但我觉得更重要的是心理负担小。
以前做一个需要地图的页面，最烦的就是先去申请 Key，然后看价格表，再估算访问量。页面还没上线，脑子里已经开始算“每月多少请求、超量怎么收费、缓存会不会违规”。访问量低的时候问题不大，一旦页面被爬虫扫了，或者产品突然火了一下，账单就可能变成事故。
OpenFreeMap 至少给了快速落地的入口。
用起来很简单
如果只是想在网页里显示地图，直接用 MapLibre GL JS 就行。
官网 Quick Start 给的核心用法大概是这样：
<script src="https://unpkg.com/maplibre-gl/dist/maplibre-gl.js"></script>
<link href="https://unpkg.com/maplibre-gl/dist/maplibre-gl.css" rel="stylesheet" />
<div id="map" style="width: 100%; height: 500px"></div>
<script>
const map = new maplibregl.Map({
container: 'map',
style: 'https://tiles.openfreemap.org/styles/liberty',
center: [13.388, 52.517],
zoom: 9.5,
})
</script>关键就是这个 style URL：
https://tiles.openfreemap.org/styles/liberty如果你以前用过 Mapbox GL JS，迁移成本也不算高。MapLibre 本来就是从 Mapbox GL JS 最后一个开源版本发展出来的。只要你没有依赖 Mapbox 2.x 之后的专有能力，很多场景基本就是换库、换 style。
Leaflet 和 OpenLayers 也能接。
不过要注意，OpenFreeMap 提供的是矢量瓦片，不是传统 raster tile。Leaflet 原生更偏 raster tile，如果要接 OpenFreeMap，需要通过 maplibre-gl-leaflet 这类桥接方案。
如果新项目要做 Web 地图，我会优先看 MapLibre，而不是再从 Leaflet 开始绕一圈。
下面这个小控件就是用 OpenFreeMap + MapLibre 做的。它没有走任何后端服务，只是在前端切换不同的 style URL。拖动地图、缩放、切换样式都可以直接试。
真正有意思的是它的服务方式
RepoInside 那篇文章标题里提到“3 亿个小文件”，这基本抓住了 OpenFreeMap 的核心。
OpenFreeMap 的技术路线很反直觉：它没有跑一个传统意义上的 tile server。根据 GitHub README，公共服务主要是 nginx 在 Ubuntu 上直接服务 Btrfs 分区镜像里的大量 hard-linked files。
说白了，就是把瓦片服务尽量压成文件系统问题。
这件事有点粗暴，但很工程。
传统想法是：既然有 3 亿个小瓦片，那我写一个服务来管理它们、查询它们、返回它们。OpenFreeMap 反过来想：既然最后都要返回静态文件，能不能让 Linux 文件系统和 nginx 直接干这件事？
它的大致链路是：
OSM planet 数据
↓
Planetiler 生成 MBTiles
↓
extract_mbtiles 拆成 Btrfs 镜像
↓
shrink_btrfs 压缩镜像
↓
服务器下载并挂载镜像
↓
nginx 直接服务瓦片文件这个设计最妙的地方，是它把运行时复杂度降下来了。
没有 tile server，意味着少一个常驻服务，少一层应用逻辑，少一批运行时状态。Linux 内核的文件缓存和 nginx 都是非常成熟的东西。能把问题交给它们，就不要自己重新造一个复杂系统。
好的工程设计不一定高级，但一定知道把问题交给谁。
项目 README 里还提到，Planetiler 让瓦片生成时间从 5 周降到 5 小时。这个数字很夸张，也说明现代开源地理工具链已经成熟不少。
它适合什么场景
我觉得 OpenFreeMap 很适合三种项目。
第一类是普通 Web 应用里的底图。
比如你有门店位置、骑行路线、城市数据可视化、旅行记录、房源展示。这类场景通常只是需要一张稳定的底图，然后把自己的点、线、面叠上去。OpenFreeMap 很合适。
第二类是想避开商业地图锁定的项目。
地图服务一旦深度接入，迁移成本很高。SDK、样式、瓦片、地理编码、路线规划，经常绑在一起。前期用起来很爽，后期价格或条款变了，就很被动。
OpenFreeMap 至少把底图这一层拆开了。
第三类是需要自托管的团队。
有些业务不想把地图请求打到第三方服务，或者需要更强的数据控制。OpenFreeMap 提供每周更新的全球 Btrfs 和 MBTiles 下载，自托管时不一定要自己从头生成瓦片。这个很关键。
因为生成全球瓦片不是小活。
自托管服务和自己生成瓦片是两回事。前者是运维问题，后者是算力、存储、数据处理问题。OpenFreeMap 把处理好的 planet tiles 放出来，能省掉不少前期成本。
别把它当全家桶
不过，别把 OpenFreeMap 当成 Google Maps 或 Mapbox 的全能替代品。
它砍掉了搜索、路线规划、实时交通、卫星影像、静态图生成、海拔查询这些重型功能，只专注于一点：矢量底图的托管。
听起来少了很多东西，对吧？
但我反而觉得这是优点。地图这行水很深，geocoding、routing、tiles、卫星图，每一块单独拎出来都够折腾一家公司。如果你的产品需要输入地址自动补全，可以去看 Nominatim、Pelias、Photon；需要路线规划，可以去看 OSRM、GraphHopper、Valhalla。OpenFreeMap 没有假装自己能包办这些事。
我挺欣赏这种克制。
反观不少开源项目，一上来就想大而全，把搜索、导航、样式编辑、数据管理、权限系统什么都塞进去，最后往往是样样通样样松。OpenFreeMap 能守住底图这块阵地，其实挺难得的。
商业使用和署名
OpenFreeMap 允许商业使用。
但地图数据来自 OpenStreetMap，样式和 schema 也有对应来源，所以署名不能省。README 里提到，如果使用 MapLibre，署名会自动显示；如果用其他客户端，或者用于印刷、视频等场景，需要手动加上对应 attribution。
实际项目里建议不要偷懒。
地图署名不是装饰，它是 OpenStreetMap 生态能长期运转的一部分。很多人免费用 OSM 数据，却不愿意显示来源，这个习惯不好。
公共实例能不能直接上生产
但这事儿没那么简单。
如果是个人项目、小网站、内部 demo、低风险业务，我觉得可以直接试。OpenFreeMap 的公共实例就是为了降低使用门槛。
但如果是核心业务，还是要谨慎。
官网明确说目前没有 SLA，也没有个性化支持。公共实例靠捐赠维持，项目也还在演进。对生产系统来说，没有 SLA 就意味着你要自己承担不可用风险。
我的判断很简单：低风险项目直接用公共实例，有一定访问量就准备降级预案，核心业务要么自托管，要么买有 SLA 的商业服务。如果地图是产品核心能力，还要把 geocoding、routing、tiles 这些层拆开设计，别全压在一个服务上。
不要把“免费”理解成“没有成本”。
免费只是账单成本低，工程风险还在。公共实例挂了，用户不会关心你是不是用的开源服务。
我对这个项目的看法
OpenFreeMap 最打动我的地方，是它没有把问题讲复杂。
它不是发明一套全新的地图协议，也不是做一个巨大的平台。它只是把已经成熟的工具组合起来：OpenStreetMap、OpenMapTiles、Planetiler、MapLibre、Natural Earth、Wikidata，再加上一套很实用的部署和文件分发设计。
这就是典型的工程型开源项目。
技术上最值得学习的地方，其实就两个词：克制。
它只做 vector tile hosting，不做搜索，不做导航，不做卫星图。这个边界让项目能保持轻量，也让用户知道该期待什么。运行时也克制，用 Btrfs 镜像、hard links、nginx 和 Linux 文件缓存去服务大量小文件。这个方案不一定适合所有人，但思路很值得借鉴：如果业务本质是静态分发，就不要急着加一层动态服务。
复杂系统最怕为了“可控”加太多控制层，最后每一层都变成故障源。
总结
OpenFreeMap 是那种“做窄但做深”的项目。
如果你只需要一张清爽的底图，不想被昂贵的 API 和复杂的授权协议绑住，它是目前很值得试的平替。别把它当全家桶用，把它当成地图服务的地基，剩下的搜索、路线、卫星图、SLA，再按业务需要往外攒。
这才是它最舒服的用法。
项目地址：
- 官网：https://openfreemap.org/
- GitHub：https://github.com/hyperknot/openfreemap
- 样式项目：https://github.com/hyperknot/openfreemap-styles
- Reddit 介绍帖：OpenFreeMap - Open-Source Map Hosting
- RepoInside 文章：OpenFreeMap：把「3 億個小檔案」變成免費地圖服務
如果你正在做一个需要地图底图的项目，我建议先试试 OpenFreeMap。至少它能让你在一开始少申请一个 API Key，少看一张复杂价格表。