通信与导航技术博客上线：从原理到代码实测的完整知识库

拖了大半年的通信与导航技术博客，今天终于正式上线了。之前一直有朋友和读者问我，什么时候能把这些年折腾过的定位、通信、信号处理相关的东西整理到一个自己的网站上，而不是散落在各种问答平台和短视频里。其实准备工作七七八八做了很久，域名、服务器、主题、内容迁移，最后卡在内容规划和页面细节上反复磨。这个博客网站的核心定位是“从原理到代码再到实测”的完整技术分享，主要覆盖卫星导航、无线定位、组合导航和通信系统几个方向。无论你是刚接触GNSS的在校学生、做定位算法开发的一线工程师，还是喜欢折腾UWB模块和RTK设备的硬件爱好者，应该都能在这里找到对胃口的文章。

1. 从零做通信导航技术博客：这个网站要解决什么问题

1.1 为什么方向偏偏锚定在“通信与导航”

可能有人会觉得通信和导航是两个方向，放在一起有点宽泛。但真做过这个领域你就会发现，这两个方向越来越分不开。现代定位系统离不开无线通信的信号结构设计，而通信网络的运行又离不开高精度时间同步和终端位置信息。早期的蜂窝网只要能打电话发短信就行，到了5G时代，定位功能被直接写进了协议标准，基站侧通过测量参考信号到达时间差来估算终端位置，精度能做到米级甚至亚米级。反过来，GNSS接收机要输出高精度结果，也依赖通信链路做差分数据的传输和改正数的播发。

所以这个博客从一开始就决定不把通信和导航割裂开来。导航定位的文章会讲信号处理和误差来源，通信相关的文章也会讲信道特性和时间同步，两者交叉的部分恰恰是我最想整理的内容。做过RTK的人都知道，载波相位差分定位对数据链质量极其敏感，差分数据哪怕中断几秒钟，模糊度解算就可能失败，整周模糊度要重新搜索。这个例子特别典型地说明了通信链路质量如何直接影响导航定位的效果，光懂卫星轨道和钟差模型还不够，还得懂数据链路的时延、丢包和带宽限制。

1.2 三类主要读者与他们各自想找的东西

建站之前我反复想一个问题：这个博客到底写给谁看。把读者画像想清楚，比决定用什么建站工具重要得多。我的判断是，通信与导航领域的技术内容大体上有三类人在找，他们的需求差别非常明显。

第一类是刚入门的在校学生，他们在学《卫星导航原理》或者《无线通信基础》的时候，发现教材往往只讲理论和公式推导，很少告诉你实际接收机解算出来的卫星星历长什么样、NMEA协议里的那些语句具体怎么解析。这类读者需要的是把书上概念映射到真实数据样本上的文章。

第二类是一线工程师，尤其在做定位算法、车载导航、无人机飞控、IoT设备定位这类产品的人。他们遇到的实际问题通常是NTRIP差分数据连接不稳定、Kalman滤波发散、UWB测距多径干扰严重。这类读者搜索到网站，要的是排查思路和可复现的代码片段。

第三类是硬件折腾型玩家，手里有u-blox的F9P板卡、ESP32加各种定位模块、或者开源SDR设备，想搭一套自己的RTK基准站或者搞个室内定位原型。这类读者的特点是动手能力强，但可能没有系统地学过信号处理，需要的是引脚连接、固件配置、参数调整和实测数据评估这类实操性极强的内容。

这三类读者的交集其实不小，共通点是都想看“真正跑过、测过、踩过坑”的内容，而不是把官方文档换个说法再抄一遍。这也是我给自己定的内容底线。

1.3 我做这件事的几个朴素出发点

除了定位和内容方向，我决定把网站正式做起来还有几个很现实的考虑。首先是技术资料的碎片化问题太严重了。我自己工作中遇到一个陌生的定位协议，经常要在几十个网页之间反复跳转，有的讲协议结构，有的讲解算流程，有的讲误差处理，看完之后脑子里还是缺一张完整的地图。既然我花了大量时间把这些碎片拼起来，不如把它沉淀成一个有目录、有分类、有交叉引用的系统内容库。

其次是写作本身对知识深度有强制校验作用。很多东西躺在收藏夹里的时候以为自己懂了，真要写成文章就会发现自己解释不清楚前因后果。比如载波相位差分里的双差模型，看资料的时候觉得每一步都有道理，但要把“为什么双差能消除接收机钟差”写成一篇让陌生人都能看懂的文章，才发现我其实没有真正理解误差传播的每条路径。写博客对作者自己也是种训练。

第三是希望有一个完全自主可控的发布阵地。以前内容散落在第三方平台，平台规则调整、审核尺度变化、甚至账号异常，都可能让积累的内容一夜之间变得不可访问。自己搭的网站可以自由决定目录结构、展示形态和内容存续周期。

2. 内容频道划分：一张通信导航知识地图

2.1 四个频道怎么划

网站的内容从第一天起就确定了四个核心频道：GNSS与卫星导航、无线定位与通信感知、组合导航与多传感器融合、定位开发实战。四个频道不是按工具或平台来划分的，而是按知识链路来划分，每个频道解决不同层次的问题。

GNSS与卫星导航频道讲的是全球导航卫星系统的基础理论、信号结构、误差源和接收机处理流程，从GPS、北斗、GLONASS、Galileo四大系统的频点和信号体制差异，到伪距测量、载波相位测量、单点定位、差分定位和RTK的实现原理。这个频道也包含卫星轨道参数、历书、星历的解析，以及NMEA 0183、RTCM 3.x协议里常用消息的具体格式和实战解析。

无线定位与通信感知频道重点覆盖通信网络赋予的定位能力，包括蜂窝网络定位（基于CID、OTDOA、UTDOA）、5G定位参考信号的测量机制、WiFi RTT测距、蓝牙AoA到达角测量、UWB高精度测距等。这个频道同时会讲这些定位技术背后的物理层信号设计，比如为什么UWB用宽带脉冲能获得更高的测距精度，天线阵列的相位差是怎么被用来估计到达角的。

组合导航与多传感器融合频道聚焦在GNSS在遮挡环境下失效时怎么用其他传感器把定位接续上，典型方案是GNSS与惯性测量单元（IMU）的组合、行人航位推算（PDR）、轮速计+GNSS融合、视觉里程计和因子图优化。这里会花比较多篇幅讲Kalman滤波及其扩展形式，包括EKF、UKF和基于因子图的优化，并用仿真数据和实际采集数据做精度对比。

定位开发实战频道是最接地气的一块，收录基于RTKLIB、u-blox、ESP32、树莓派等硬件平台的实战教程，包括接收机配置、原始观测量采集、后处理解算、基于Android定位接口的融合定位App开发、静态和动态精度评估方法等。这个频道的文章都附带完整代码和测试数据，方便读者自己复跑。

2.2 一篇典型技术文章的内部骨架

为了让不同频道的文章风格统一，我在内容规范里定了一套内部模板。每篇文章必须包括四个部分：背景与问题、原理拆解、实现过程、实测结果与讨论。背景与问题部分说明这篇文章解决什么场景下的什么问题，读者会带着疑问进来；原理拆解部分用尽可能通俗的语言把关键机制讲透，公式只保留必要的，但每个符号的含义必须定义清楚；实现过程部分给出可运行的代码、具体参数和操作步骤；实测结果与讨论部分放采集到的真实数据、误差统计表格和结论分析。

这套模板不是死规定，但可以避免写成一堆没有上下文的代码片段。比如写RTKLIB的rtkpost使用教程，就既要说明RTK的定位原理和误差源，也要设计一套真实的双频观测数据作为输入，最后给出定位精度统计。这样初学者能跟上思路，有经验的人也能直接跳到最后看结果。

我特别要求自己在文章里标注“参数为什么是这个值”。比如接收机动态等级设置成high而不是static，是因为测试载体处于运动状态而最大加速度超过了低速模式的门限；Kalman滤波过程噪声协方差矩阵Q里的某个分量设成1e-4，是因为根据IMU器件噪声标称值和采样频率推算出来的。这种“为什么”的表述是把文章从操作手册升级为经验分享的关键。

2.3 上线初期与后续三个月的内容重点

网站上线初期，内容重心放在最能体现通信与导航交叉的几篇主题上。第一篇深度文章是GNSS信号结构入门，从载波、伪码、导航电文三层结构讲起，结合GPS L1 C/A和北斗B1I信号的实际参数做对比。第二篇是NMEA 0183协议解析，用一段Python代码解析真实采集的GNGGA和GNRMC语句，帮助读者快速建立对定位数据格式的直观认识。

第二个月内计划发布RTK定位原理系列，从单点定位的误差来源讲到载波相位双差模型，再到模糊度解算的LAMBDA算法，配套RTKLIB的实操和静态基线解算精度评估。第三个月的重点会转向通信感知方向，包括5G定位参考信号的测量机制、UWB的DS-TWR测距协议实现，以及用ESP32-UWB模块搭建室内定位原型的完整教程。这个节奏大约保持每周一篇，宁缺毋滥。

3. 建站技术选型：从本地写作到服务器上线的完整链路

3.1 为什么放弃了动态博客选择了静态站点

建站方案选择上我纠结了相当一段时间，最后选定的是Hugo静态站点生成器，部署在一台云服务器上，用Nginx做Web服务。这个选择看起来平平无奇，但背后有一条清晰的取舍逻辑。

第一轮比较的是动态博客和静态博客。动态博客（WordPress、Halo、Typecho这类）有现成的后台管理界面，写文章像用Word一样，对非技术人员很友好。但它们都需要数据库、需要定期更新补丁、需要处理并发和缓存问题，安全维护成本不低。静态站点没有数据库、没有服务端脚本执行，页面在构建时就已经生成为纯HTML，被攻击面小很多，访问速度也天然快。对于技术博客这种“内容更新频率低、读多写少”的场景，静态站点几乎是为它量身定制的。

第二轮比较的是具体的静态站点生成器。我把主流的几个都试了一遍，对比结果如下表：

我最终选Hugo，核心原因是它在构建速度和内容组织上最匹配我的需求。我计划写的GNSS算法类文章会包含大量公式、代码块和表格，网站可能有几百上千篇以后，Hugo百万字级别的内容构建仍然能在一两秒内完成。而且Hugo的内容目录结构直观，每个频道的文章对应一个子目录，管理起来非常自然，不需要额外建数据库去维护分类关系。

3.2 写作、构建与发布的具体流程

确定了Hugo之后，我再接一个自动化发布链路，做到“本地写Markdown、推送到服务器、自动构建上线”。这个流程让我不用每次写完文章都登录服务器执行命令，省去了重复劳动。

整个流程分成三个环节。本地环节用Visual Studio Code写Markdown源文件，每篇文章开头是一个toML格式的front matter块，里面声明标题、日期、分类、标签、摘要、是否草稿等元信息。写完草稿后在本地执行hugo server进入预览模式，浏览器实时查看渲染效果。确认没问题后把文章状态从draft改为false，再commit并push到远程的Git仓库。

服务器端环节部署了一个webhook接收器。每当我push代码到指定分支，服务器收到通知后自动执行拉取最新代码、运行hugo构建、把生成的public目录同步到Nginx的站点根目录这一连串操作。整个构建过程大概几秒钟内就完成。Nginx这边配置了gzip压缩、静态资源缓存头和HTTPS证书的自动续期，访问量低的时候一台入门云服务器就能轻松扛住。

我特别建议静态博客的部署一定要尽早接入自动化发布。如果每次发文章都要手动ssh上服务器执行hugo命令，更新频率会被拖慢，久而久之就不想更新了。自动化之后，写文章和发文章变成了两个完全独立的事情，写完了推一下代码就完事，心理负担小很多。

3.3 评论、搜索、公式与代码高亮的实现

静态站虽然没有数据库，但该有的交互功能还是要有的，这部分我花了比较多精力。

评论系统没有用现成的第三方托管服务，因为那些服务一般靠外链JavaScript加载，在国内网络环境下访问很不稳定，排在页面里的加载失败会拖慢整体体验。最后选择了自建的Waline评论系统，部署在同一个云服务器上，数据存在SQLite里。这样评论数据完全自主可控，不会被第三方平台的条款和服务稳定性绑架。Waline支持Markdown语法、邮件通知、敏感词过滤和简单的后台管理，对技术博客来说功能完全够用。

站内搜索用的是Hugo生成的本地搜索索引。构建时Hugo会把所有文章内容解析成一个JSON索引文件，前端JavaScript在用户输入关键词时对这个索引做模糊匹配和结果高亮。这个方案的好处是完全不需要外部搜索服务，也不用担心搜索接口的配额和费用问题。当前文章量不大，本地搜索的性能完全够用，等以后文章过千篇再评估是否上全文检索引擎。

数学公式渲染选了KaTeX而不是MathJax。KaTeX是KaTeX库的快速渲染方案，渲染速度比MathJax快不少，尤其是移动端性能差异比较明显。GNSS算法类文章经常有大量公式，页面一旦渲染卡顿非常影响阅读体验。代码高亮用Hugo内置的Chroma引擎，支持超过200种语言，离线构建时就已经完成高亮，不需要前端再加载JavaScript高亮库，减少了页面的体积。

4. 正式上线前的最后一百米：踩过的坑与修复过程

4.1 数学公式在移动端渲染错乱的排查

上线前最头疼的Bug是数学公式在移动端渲染错乱。桌面浏览器里公式渲染一切正常，但用手机打开文章页面，部分公式会歪掉，比如上下标堆在错误的层级位置，多行公式的对齐符失效，有时候公式直接就超出了屏幕宽度。

一开始我怀疑是KaTeX版本的问题，升级到最新版本之后重新测试，问题依然存在。后来我把问题公式单独抽出来排查，才发现根源有两个。第一个是KaTeX自动渲染的触发时机和Hugo主题的页面加载逻辑冲突，页面内容还没有完全插入DOM树就开始渲染公式，导致部分公式被跳过或渲染位置不对。解决办法是改成手动触发渲染，等window.onload事件和页面内容插入完成之后再调用renderMathInElement。

第二个坑是Markdown解析器会优先处理特殊字符，导致公式里的反斜杠、下划线、大括号在传到KaTeX之前已经被转义或截断。比如在Hugo的Markdown规则里，公式含下划线的变量名会被当作斜体标记，反斜杠会被当成转义字符吃掉。最后我的处理方案是把这些特殊场景用Hugo的shortcode封装一层，定义独立的公式短代码，让内容不经过Markdown默认解析流程，直接原样传给KaTeX。这个改动虽然增加了一点写作时的输入负担，但彻底杜绝了公式解析冲突。

4.2 站内搜索索引不更新的诡异问题

网站上线内测的时候，我发布了一篇新文章，文章页正常出现在列表里，但站内搜索怎么都搜不到这篇新文章。当时的第一反应是搜索脚本有问题，排查了前端JavaScript的请求逻辑、关键词匹配函数，都没找到问题。

后来我把浏览器开发者工具打开直接看搜索接口请求返回的JSON索引文件，发现索引里的文章列表根本不是最新的。问题定位到服务器构建流程上：webhook触发构建时，hugo命令虽然执行成功，但生成的索引文件路径没有更新到最新内容。再深挖发现是Nginx对public目录下的json文件设置了比较激进的缓存响应头，浏览器把我测试时候的旧索引文件缓存在了本地，每次搜索拿到的都是缓存，自然搜不到新内容。

修复方案是调整Nginx的缓存策略，html和json这类经常更新的文件设置no-cache，图片、CSS、JavaScript这类带指纹的静态资源才设置长缓存。另外我在发布流程里也增加了一步，构建完成后清一次服务器上的缓存目录，从源头避免新旧文件混杂。

4.3 图片资源CDN与源站不同步的教训

网站首发文章里有几张GNSS接收机实测环境的照片，发布后发现部分读者看到的图片还是旧版本，换了新图但页面加载出来的始终是原来的图。这个问题主要出在我给图片配置了对象存储加CDN加速，结果在上传新图片时文件名没有变化，CDN边缘节点上缓存的老图片迟迟不失效。

处理这个问题的标准做法是给文件名加上内容哈希作为版本号，内容变了文件名就变，CDN节点上的旧缓存自然不会被引用。但当时文章已经写完，上百张图片的文件名要批量改，重命名工作量大还容易出错。最后的临时方案是在CDN控制台强制刷新了相关URL的缓存。我建议技术博客在建站初期就养成图片资源带版本号的习惯，否则内容更新频率高了之后，这种缓存问题会反复出现。

在Nginx配置层面，我还为图片专门配置了按扩展名区分缓存时间的规则。归档类图片目录可以缓存时间长一些，而文章封面这类经常调整的资源关闭缓存或者短缓存，这样兼顾了加载速度和内容更新及时性。

4.4 SEO收录与站点地图的细节

网站上线后的第一周，我做了提交搜索引擎收录的工作，这部分有一个容易忽略的细节值得单独说说。Hugo默认就能生成sitemap.xml，但如果没有正确配置站点生产环境的URL地址，生成出来的sitemap里的链接会是localhost之类的开发地址，搜索引擎爬虫拿到的全是无效链接，收录自然无从谈起。

我把站点的baseURL配置成实际的域名之后，重新生成了站点地图和每篇文章的canonical标签。canonical标签的作用是指示搜索引擎这个页面唯一的标准URL，避免因为带参数或大小写不同的URL导致权重分散。接着我在robots.txt里明确声明允许抓取sitemap的路径，并把XML格式的站点地图提交到搜索平台的站长工具里。

还有一个细节是文章URL的规范化。Hugo默认按内容目录结构生成URL，我配置了URL规则为“年份/月份/文章别名”的统一格式。这样做的好处是文章迁移目录时URL不会变，搜索引擎积累的权重不会因为改目录结构就丢了。

5. 上线只是起点：更新节奏、选题来源与反馈闭环

5.1 每周一篇的更新承诺与选题来源

网站正式上线之后，我把更新频率定成每周至少一篇深度长文，这个节奏相比日更博主来说不算高，但也足够支撑内容的持续性。技术深度类文章一周能产出一篇已经需要投入不少时间，尤其是涉及算法原理和实测数据的文章，从查资料、跑实验到成稿经常要跨好几天。

选题来源主要有三个渠道。第一个是自己在工作和研究里遇到的问题，这类选题写起来最有底气，因为有真实的项目背景和一手数据。第二个是行业论文和标准文档里的关键技术点，比如RTCM协议里某个新消息类型的设计动机，这些内容适合做原理向的深度解读。第三个是社区里反复出现的高频问题，比如“为什么我的RTK固定率上不去”“ESP32能不能同时跑定位和通信”，这些真实需求最能反映读者的痛点。

为了保证选题不枯竭，我在本地维护了一个内容池文档，随时记录灵感和待写主题，并给每个主题标了优先级、预估篇幅和参考资料链接。每周从池子里挑一个最成熟的主题开始写，写完再补新的想法进池子，形成良性循环。

5.2 读者反馈怎么进入内容迭代

技术博客如果只有输出没有反馈，就很容易变成自说自话。我在每篇文章底部都留了评论区和邮件联系方式，并且给自己定了一条硬规矩：前三天内的每一条评论都尽量回复。评论区的提问往往能暴露出文章没有讲清楚的地方，这些地方就是后续文章要补的内容。

比如有读者看了NMEA协议解析的文章后留言问，为什么GNGGA语句里的定位质量指示是1代表单点定位、2代表差分定位而不是反过来。这个问题的答案藏在NMEA标准文档的字段定义里，但读者会产生疑问本身就说明我的文章在状态字段的解释上过于简单了。于是我在后面补充了一篇专门的短文，把定位状态的判断逻辑和常见异常状态列成了一张表，并且顺手完善了原文章的对应段落。

这种反馈驱动的迭代方式，能让内容是活的而不是一潭死水。我也会定期看网站访问日志里的搜索关键词，哪些词把用户带到了站点，就能更清楚地知道读者实际在找什么。比如上线后有一段时间“载波相位”“模糊度固定”这两个词的搜索来源明显增多，我就知道读者对RTK深入原理的需求比预想中更大，所以后续内容计划里把LAMBDA算法的文章提前了。

5.3 给也想开技术博客的人的建议

在把网站做到正式上线的整个过程里，我最大的体会是：做技术博客最高效的路径不是一开始就追求大而全的平台，而是先用最简单的方式跑通写作-发布-反馈的闭环。很多人花了很多时间在选主题、换框架、折腾服务器配置上，结果真正花在写文章上的时间反而很少，这是本末倒置的。

我的建议是需求驱动选型。如果你现在还没开始写，那Hugo加云服务器这套方案足够用了，甚至可以先用更简单的方案跑起来，比如在笔记软件里先积累内容，等真正有了稳定输出再说建站的事。反之如果已经有大量内容需要迁移，就优先考虑内容迁移成本低、扩展性好的方案。

另外一件非常值得做的事是尽早把“文章发布”和“网站维护”这两件事拆开。内容创作本身已经足够消耗精力，如果每次发文章还要处理服务器问题，很快就不想写了。自动化流程虽然前期要花一天时间搭好，但后续的收益是持续性的，发文章的摩擦成本被降到最低之后，才能真正把注意力放在写内容本身。

做这个站的过程中我反复重写过很多次开局方案，最后跑通的反而都是一些简单直接的做法。网站上线之后，我依然会按照自己定的节奏一篇一篇写下去，在持续产出内容的过程中不断修正方向。如果你也在做类似的事，或者对某个通信导航话题有强烈的兴趣，欢迎在评论区告诉我你的想法。