核心在于数据预处理、容器化服务与高效存储：必须将瓦片转为MBTiles单文件格式，使用maptiler/tileserver-gl镜像，通过Docker精配端口、挂载和资源限制部署，并验证接口响应、日志及前端加载效果。
用 Docker 实现离线地图瓦片加速服务，核心在于“数据预处理 + 容器化服务 + 高效存储”，不是简单跑个镜像就完事。关键是要让瓦片读得快、查得稳、部署轻、扩容易。
选对镜像：tileserver-gl 是当前最稳妥的开源选择
别被各种 MapTiler 商用版、自研 Node 服务带偏。生产环境验证最多、无授权限制、支持 MBTiles 和矢量瓦片、文档齐全的，还是 maptiler/tileserver-gl。它基于 Rust 和 GL 原生渲染，单核吞吐高，内存占用低，特别适合内网轻量部署。
- 镜像拉取：
docker pull maptiler/tileserver-gl:latest - 只认 .mbtiles 文件（SQLite 封装），不接受原始文件夹结构（如 z/x/y.png）——这是性能底线，千万不能跳过转换步骤
- 默认监听容器内 8080 端口，返回标准 XYZ/TMS 接口，Cesium、Leaflet、OpenLayers 全兼容
数据必须转成 MBTiles：千万避免“千万小文件”陷阱
直接挂载几百万个 PNG 文件到容器里？Linux ext4 文件系统会卡死，Docker volume 读取延迟飙升，浏览器加载首屏瓦片可能要 3 秒以上。正确做法是提前打包：
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 用 tippecanoe（栅格切片）或 Planetiler（矢量切片）生成 .mbtiles
- 例如裁剪北京市并生成 0–15 级矢量瓦片：
planetiler --input=beijing.osm.pbf --output=beijing.mbtiles --max-zoom=15 - MBTiles 是单文件 SQLite 数据库，顺序读写高效，且支持
PRAGMA mmap_size = 268435456;提升 mmap 性能 - 把生成好的
beijing.mbtiles放进宿主机目录，比如/opt/maps/data/
Docker 启动要精配：端口、挂载、资源三者缺一不可
一个稳定可用的启动命令，要同时解决访问通、数据可见、不爆内存三个问题：
- 端口映射建议避开 80/443/8080 这些常被占的端口，比如用
-p 8092:8080 - 挂载必须用绝对路径，且确保容器内
/data能读到 .mbtiles：-v /opt/maps/data:/data - 加
--memory=2g --cpus=2限制资源，防止单个服务吃光整机资源（尤其和 PostGIS/Nominatim 共存时） - 完整示例：
docker run -d \<br> --name tileserver-beijing \<br> --restart=always \<br> --memory=2g --cpus=2 \<br> -p 8092:8080 \<br> -v /opt/maps/data:/data \<br> maptiler/tileserver-gl:latest
上线后必须验证的三件事
容器跑起来只是第一步，真正决定“是否加速”的是这三项：
-
测接口响应：用 curl 请求一张瓦片，看耗时是否在 10–30ms 内：
curl -o /dev/null -s -w 'time:%{time_total}s ' 'http://localhost:8092/data/beijing/{z}/{x}/{y}.pbf' -
查日志有无报错：运行
docker logs tileserver-beijing，确认没出现file not found或database is locked -
前端加载验证：在 Leaflet 中配置
L.vectorGrid.protobuf(..., {url: 'http://<host-ip>:8092/data/beijing/{z}/{x}/{y}.pbf'})</host-ip>，拖动缩放观察是否流畅无白块
