大家好，我是书樱。

今天，我将开启一个全新系列，记录一个我命名为“PICO Radar”的项目。其核心使命是解决一个在大型、多人、同空间VR体验中普遍存在的物理安全问题：由于沉浸在虚拟世界中，玩家无法感知现实中其他人的位置，从而导致碰撞风险。PICO Radar旨在通过在局域网（LAN）内建立一个低延迟、高精度的位置共享网络，来消除这一隐患。

这第一篇日志，不关于代码实现，而关于构建我们项目“宪法”的思辨之旅——那些定义了项目技术灵魂的架构决策。

核心范式：中心化服务器与“单一事实来源”

面对一个多节点状态同步的问题，我们首先确定了系统的宏观架构。我们选择了经典的客户端/服务器 (Client/Server) 模型。

• 中心服务器 (Server): 作为系统的权威核心，它将是所有玩家状态的“单一事实来源”（Single Source of Truth）。这意味着任何关于玩家位置、姿态和身份的最终裁定都源于此处。这种中心化的设计极大地简化了状态一致性问题，避免了在对等网络（P2P）中可能出现的复杂状态冲突和网络分裂（Network Partition）问题。
• 客户端 (Clients): 每个PICO设备上运行的轻量级库，其职责纯粹：精确捕获本地玩家数据上报给服务器，并忠实地渲染从服务器接收到的所有其他玩家的状态。

技术栈的初步选择旨在最大化性能与效率：

• C++17: 赋予我们必要的底层控制能力和极致的执行效率，这对于延迟敏感型应用至关重要。
• WebSocket: 在TCP之上提供了一个持久化、全双工的通信信道，相比于HTTP轮询，其开销极低。
• Protocol Buffers (Protobuf): Google出品的高效、强类型的二进制序列化方案，确保了网络负载的紧凑性和解析速度。

深度权衡：网络协议栈的抉择 (TCP vs. UDP)

蓝图初定，我们立即面临了第一个深刻的技术挑战：“在追求低延迟的局域网环境中，为何不采用UDP，甚至直接在数据链路层（L2）进行原始以太网帧广播？”

这是一个极具诱惑力的提议，它迫使我们深入审视OSI模型的不同层次及其哲学。

• L2/UDP的理论优势: UDP（用户数据报协议）工作在传输层（L4），它提供了一种“即发即弃”（fire-and-forget）的服务。它不保证消息的送达、顺序或唯一性。这使得其头部开销小，延迟理论上更低。在L2上操作则更为极端，但能获得纳秒级的延迟优化。

• TCP的现实价值: TCP（传输控制协议）同样在L4，但它是一个面向连接的协议。它内建了复杂的机制来保证：

  1. 可靠性: 通过序列号和确认（ACK）机制，确保每个数据包都能送达。
  2. 顺序性: 确保数据包按发送顺序被接收端重组。
  3. 流量与拥塞控制: 动态调整发送速率，避免压垮网络。

我们的最终裁决是：坚定地选择基于TCP的WebSocket。理由如下：在VR同步的场景中，一个玩家的虚拟化身因网络丢包而“瞬移”或“卡顿”，对用户体验的破坏是毁灭性的。TCP提供的可靠性和顺序性从根本上杜绝了这类问题。在现代局域网（尤其是Wi-Fi环境）中，TCP引入的稳定、可预测的几毫秒延迟，远比UDP不可靠性带来的体验灾难更有价值。我们牺牲了理论上的微小延迟，换取了用户感知的绝对流畅。

系统韧性设计：从“能用”到“可靠”

一个能在理想条件下运行的系统只是玩具。一个真正的产品必须具备在非理想条件下的“韧性”（Resilience）。

1. 对抗网络抖动 (Jitter): 为了确保远程玩家的移动看起来平滑，而非一连串的离散跳跃，客户端必须实现插值（Interpolation）与外插值（Extrapolation） 算法。通过一个微小的延迟缓冲区（Jitter Buffer），我们可以平滑地渲染出玩家在两个已知位置之间的移动（Lerp/Slerp），从而创造出“感知一致性”（Perceptual Coherence）。
2. 优雅处理断连: 服务器必须实现严格的心跳与超时机制。WebSocket协议内建的Ping/Pong帧是实现心跳的完美工具。若服务器在预设窗口（如5秒）内未收到某客户端的任何响应，则会判定其超时断连，并立即向所有其他客户端广播该玩家的离线消息，防止“幽灵玩家”的存在。
3. 带宽优化: 在一个可能有多达20个玩家的场景中，网络带宽并非无限。我们决定，客户端仅在本地玩家的位置或姿态变化超过预设阈值时才发送更新。一个静止的玩家不应产生任何网络流量。

工程化灵魂：构建“产品级”软件

当讨论转向构建、依赖管理和测试时，项目的性质从一个“原型”升华为一个严肃的“工程项目”。

• 可移植与可复现的构建: CMake作为我们的元构建系统，配合Ninja构建工具，确保了在我的Arch Linux开发环境和未来任何目标平台（如Windows Server）上的一致性。所有第三方依赖通过vcpkg的清单模式（vcpkg.json）进行管理，确保了任何开发者都能一键获取完全一致的依赖版本，实现了真正的“可复现构建”。
• 高内聚、低耦合的模块化: 我们将系统解耦为多个独立的模块（core, network, common等）。core模块包含了所有核心业务逻辑（如玩家注册表），但完全不依赖任何网络代码。这种设计使得我们可以对核心逻辑进行纯粹的单元测试，甚至无需编译网络模块，极大地提升了可测试性。
• 面向集成的客户端库: client_lib将被设计为一个独立的静态库，它会提供一个简洁、稳定的C-Style API或纯C++接口。这确保了Unreal Engine或其他游戏引擎可以轻松地集成它，而无需关心其内部复杂的网络实现，避免了紧密耦合。
• “无硬件”的模拟测试: 我们如何在一个PICO头显都没有的情况下，测试一个能容纳20个玩家的服务器？答案是开发一个mock_client。这个模拟客户端可以通过脚本启动任意数量的实例，对服务器进行全面的功能、负载与压力测试。这是确保我们开发不被物理硬件瓶颈束缚的关键决策。

点睛之笔：用户体验与专业交付

最后，两个关键特性将项目的用户体验和专业性提升到新高度：

1. 零配置服务发现: 在VR中手动输入IP地址是糟糕的体验。我们决定采用UDP广播实现服务发现。客户端启动后，会自动向局域网发送一个发现请求，服务器响应后，客户端即可自动获取连接所需的所有信息。这是“零配置网络”（Zeroconf）理念的体现。
2. 完备的文档与度量: 我们规划了一整套文档（DESIGN.md, API_REFERENCE.md, USER_GUIDE.md）和正式的性能基准测试流程。我们要用精确的数据（延迟、CPU/内存占用、带宽消耗）来度量和证明我们的系统性能。

总结：我们的设计原则

这次思想的远征，为PICO Radar项目确立了四大核心设计原则：

1. 可靠性优于理论延迟: 用户的感知流畅度是最高优先级。
2. 状态的中心化权威: 简化一致性，确保无冲突。
3. 面向韧性与异常设计: 系统必须在真实世界的混乱中生存。
4. 工程化与可测试性先行: 专业的流程是质量的最终保障。

蓝图已定，基石已稳。下一次，我们将开始用代码将这幅蓝图变为现实。

下次见！

—— 书樱