嗨，大家好，我是 chenxuan。作为一个既热爱代码又痴迷于在地图上规划路线的开发者，我常常陷入一种深深的无力感。你有没有过这样的经历：兴致勃勃地想要开发一个基于地理位置的应用，或者只是单纯想规划一次完美的自驾游，结果却被各种地图服务商的“高墙”撞得头破血流？

说实话，这种体验简直让人抓狂。要么是每天那少得可怜的免费配额，稍微一超就报错；要么是必须实名认证、绑定信用卡，甚至还要忍受企业审核的漫长等待；geng别提那些无处不在的跨域限制和坐标系转换的噩梦了。就在某个被百度地图API报错信息折磨得睡不着觉的深夜，我决定：既然没有完美的轮子，那我就自己造一个！于是RoadbookMaker 诞生了。

市面上绝大多数地图工具，无论是百度、高德还是天地图，dou绕不开“Key”这个门槛。对于个人开发者或者只是想Zuo个小工具自用的人来说这无疑是一种巨大的负担。记得以前为了测试一个简单的地点搜索功Neng，我得去注册账号，创建应用，还要忍受各种合规性检查。geng糟糕的是一旦你的应用稍微有点流量，或者仅仅是自己在调试时手抖多刷新了几次那个冰冷的“访问次数限制”提示就会立刻出现在屏幕上。

这不仅仅是技术问题，geng是心理上的束缚。我们在创作的时候，本该关注的是逻辑和体验，而不是整天盯着控制台的配额余量。这也是我开发 RoadbookMaker 的初衷——我要一个完全属于我自己的、不受任何限制的地图世界。

在这个项目中，我彻底抛弃了对传统商业地图API的依赖。它不需要你申请任何Key，不需要注册账号，甚至不需要联网。所有的数据dou在你的掌控之中，这种安全感，是用多少个付费API Keydou换不来的。

在深入了解如何使用前，我想先聊聊这背后的技术实现。毕竟作为一名极客，我不仅想要工具好用，还想要它“性感”。为了实现那种极致的轻量和流畅，我在技术选型上Zuo了一些大胆的尝试。

现在的Web开发动不动就是React、Vue，还要配Webpack、Vite，构建一套环境下来硬盘dou要占几个G。但对于 RoadbookMaker 这样的工具来说这些庞然大物实在是杀鸡用牛刀。

我选择了Zui原生的 Vanilla JavaScript，配合地图界的老牌强者 Leaflet.js。你可Neng会问，不用框架怎么行？事实证明，去掉那些层层封装的抽象后代码反而geng加清晰直接。Leaflet本身就是一个非常成熟、插件丰富的开源库，它对移动端的支持极佳，而且体积极小。这样Zuo的好处是显而易见的：页面加载速度飞快，没有任何构建步骤，双击html文件就Neng跑，也为后续实现完全离线打下了坚实的基础。

虽然前端尽量Zuo到了静态化，但为了处理一些复杂的逻辑，我还是需要一个后端服务。这里我毫不犹豫地选择了 Go 配合 Gin 框架。

为什么是Go？因为它编译出来的二进制文件是单体的，不依赖任何乱七八糟的运行时环境。这意味着部署它就像上传一个文件一样简单。配合Docker的话，镜像体积Ke以压缩到极致，资源占用低到几乎Ke以忽略不计。对于这种需要长期运行在后台的小工具来说Go的高并发性Neng和低内存占用简直是完美的选择。

这里有个小窍门，也是 RoadbookMaker Zui核心的黑科技之一。既然前端不直接调用商业API，那数据从哪来？

答案就在后端的 API代理 模块。我在后端搭建了一个中转服务，当前端发起搜索请求时后端会代为去请求百度、天地图等服务。在这个过程中，后端默默处理了所有脏活累活：比如处理令人头秃的跨域问题，以及Zui关键的——坐标系转换。

大家dou知道，国内地图普遍使用GCJ-02，而标准的GPS数据是WGS-84，OpenStreetMap又是另一种标准。Ru果在前端处理这些转换，不仅暴露了Key，性Neng也是个问题。现在后端把这些数据“洗”了一遍，将火星坐标统一转换成前端需要的格式，再把干净、统一的数据吐回去。前端根本不需要知道这些数据是从哪来的，它只管显示。这不仅巧妙地绕开了前端直接调用API的风险，也彻底解决了Key暴露的后顾之忧。

说了这么多技术细节，这东西到底好不好用？让我们抛开代码，以一个普通用户的视角，来规划一次“周末城市漫步”吧。

打开网站，映入眼帘的是一张极其清爽的地图界面。没有乱七八糟的广告，没有复杂的登录弹窗，只有纯粹的地图和你的目的地。你Ke以通过顶部的搜索框直接输入“咖啡馆”、“书店”或者具体的地址，或者像我一样，喜欢直接在地图上漫无目的地游荡，用鼠标滚轮缩放，寻找那些隐藏在巷子里的小店。

当你发现了一个不错的公园，想把它作为起点，只需在地图上单击一下。一个醒目的标记点就出现了。接着，你又发现了几公里外有一家评分hen高的独立书店，再点一下。就这样，我们在地图上撒下了一串兴趣点。

这时候，它们还是孤立的。没关系，RoadbookMaker 提供了非常直观的连线功Neng。你Ke以轻松地将这些点连接起来形成一条完整的路线。kan着屏幕上那条蜿蜒的线，仿佛Yi经kan到了周末的行程在眼前展开。

路线画好了但细节决定成败。单击任意一个标记点，右侧会平滑地滑出一个详情面板。这里的交互设计我花了不少心思，力求不遮挡视线的同时提供Zui大的操作空间。

在面板里你Ke以给这个点起个名字，比如“午后咖啡小憩”，或者备注一下“记得带相机”。Ru果你对连线的形状不满意，同样单击连接线，在详情面板里也Neng进行调整。这种所见即所得的编辑体验，真的非常解压。你不需要去写什么配置文件，也不需要去理解复杂的GIS术语，一切就像在画板上涂鸦一样自然。

规划完成后你肯定不想这份心血只存在于浏览器里。工具支持将成果导出，无论是分享给朋友，还是进行本地备份，dou只是一键操作的事。你Ke以把这份路书发到手机上，即使在没有网络的环境下只要提前加载了离线瓦片，依然Ke以正常查kan路线。

我们生活但作为开发者，我们深知网络的不可靠性。当你身处深山，或者是在信号极差的国外漫游时那些依赖在线API的地图应用瞬间就会变成一块废铁。

RoadbookMaker 对离线Neng力的重视，源于我一次在野外徒步时迷路的经历。那时候，手机信号全无，在线地图根本刷不出来。从那以后我就发誓要Zuo一个不依赖网络的工具。

通过结合开源的瓦片地图数据，我们Ke以预先下载好特定区域的地图包。配合Leaflet强大的离线渲染Neng力，即便你拔掉网线，RoadbookMaker 依然Neng流畅地缩放、漫游。这对于户外爱好者、骑行者或者是需要在内网环境工作的行业来说简直就是救命稻草。这让我想起了另一款优秀的开源软件 Organic Maps，它也是基于OpenStreetMap数据，专注于隐私保护和离线导航。Ke以说在“离线自由”这条路上，我们有着相同的默契。

你的每一次点击、每一个搜索记录dou可Neng被商业化。你去过哪里、喜欢去哪里这些数据在巨头眼里是金矿，但在我kan来这是隐私。

使用 RoadbookMaker，所有的路线数据、标记信息dou存储在你自己的服务器或本地设备中。没有追踪Cookie，没有后台行为分析，geng没有数据贩卖。这种“无感”的隐私保护，恰恰是对用户Zui大的尊重。特别是对于一些敏感区域的规划，或者是企业的内部路线管理，这种自托管的方式Neng提供Zui高级别的安全感。

目前，RoadbookMaker Yi经具备了基本的框架和核心功Neng，但这仅仅是个开始。它不追求大而全，而是专注于将“路线规划”这一核心体验Zuo到简单、纯粹、不受限制。

既然是开源项目，我就希望Neng把它变成一个大家共同打磨的作品。现在的版本可Neng还有一些粗糙，UI细节还有优化的空间，或者你发现了某个坐标转换的Bug，甚至你有geng好的想法，dou非常欢迎提Issue或者直接提交Pull Request。

Ru果你觉得这个项目帮到了你，或者你也认同这种“摆脱束缚、回归极客”的理念，请在 GitHub 上给我一个 Star ⭐！你的每一个Star，dou是我在深夜里继续敲代码的Zui大动力。

Zui后 附上项目地址，欢迎大家去体验，去折腾，去创造属于你自己的地图故事！