基于Qt与TCP长连接的C++跨平台云笔记同步实践

简介面向学习 C 跨平台客户端与网络编程的学生和开发者这份资料围绕基于 C/S 架构的云笔记平台展开采用 C、TCP 与 Qt 实现注册登录、笔记新建查看修改删除、云端存储、管理员审核与多操作系统同步等功能可用于课程设计、毕业设计选题及 Qt 网络项目参考。压缩包仅含 1 个 PDF 文件大小约 1.48MB篇幅集中便于通读和检索。已有 241 人学习下载。文档从需求用例建模、总体功能设计写到具体实现与测试涵盖 Qt 跨平台 API 封装、TCP 可靠传输、笔记文件与用户信息存储结构以及 Windows、macOS、Ubuntu 多端同时登录验证能帮助读者理解 C/S 云笔记的模块划分、通信流程与落地路径。1. 三个系统各开一个客户端笔记还能对上号C 跨平台云笔记这个题目看着像课程设计真拆开看它把 C 云服务里最朴素的 TCP 长连接、文件存储、Qt 跨平台界面三件事串成了一条完整链路。场景很具体一台 Windows 笔记本、一台 macOS 台式机、一台 Ubuntu 测试机同一个账号分别登录在任意一台新建或者修改笔记点保存之后另外两台按一下刷新就能看到最新内容。整套东西没有 Web 前端、没有 MySQL、没有云端对象存储服务端把笔记当成普通文本文件写进目录客户端用 Qt 画界面中间靠自定义的 TCP 报文说话。适合两类人一类是想找一个能编译、能跑、代码量又不至于把人淹死的 Qt 网络编程练手项目另一类是手头有个小工具想做成多端同步需要看看 C/S 架构下协议、存储、并发这几块怎么拼起来。接下来从技术选型一路拆到能改的地方每一段都落到目录、报文或者代码上。2. 技术选型与跨平台架构Qt、TCP 和 C/S 怎么分工跨平台这个词被用得很泛落到这个项目上它指的是同一套 C 源码在三个操作系统上各自编译出原生可执行文件界面控件、socket、文件路径全部由 Qt 抹平业务代码基本不改。这跟 Electron 那种把浏览器打包进去的思路完全不同好处是启动快、内存占用低、能直接调用系统底层 API代价是每个平台都得装一遍 Qt 开发环境、各自编译。项目选择 C 加 Qt 加 TCP 的组合本质上是在“少依赖、可控、能演示完整链路”这三个目标之间取了个平衡点。2.1 Qt 到底替开发者屏蔽了哪些差异Qt 的做法不是套一层虚拟机而是针对每个平台写一套底层实现再用统一的 C 接口暴露出来。QFile在 Windows 上走的是宽字符路径在 Linux 上是 UTF-8 字节路径调用方只管传QStringQTcpSocket在三个平台上分别封装 Winsock、BSD socket信号槽的触发时机却保持一致QWidget的绘制分别对接 GDI、Cocoa、X11。对于云笔记这种以表单、列表、文本框为主的界面Widgets 模块足够用不需要引入 QML 那一套渲染管线。真正让跨平台变简单的是 Qt 把“路径分隔符”和“文本编码”这两件最容易翻车的事收进了自己的类型系统。项目里所有文件操作都用QDir、QFile、QFileInfo拼接路径用QDir::filePath()而不是手写斜杠读出来的字节统一按 UTF-8 解码。这套约定只要守住同一份存储层代码在 Windows 和 Linux 上跑出来的目录结构是一致的。常见做法是在工程根目录放一个resources/存图标、样式服务端的数据目录则通过启动参数或者配置文件指定绝不硬编码绝对路径否则换台机器就得改源码。2.2 TCP 长连接与报文边界为什么不用 HTTP 轮询笔记的增删查改是典型的小数据量、高频交互用 HTTP 每次建连、带一大堆头部字段在这个体量下反而累赘。项目直接开一个QTcpServer监听端口客户端登录成功后保持QTcpSocket连接不断后续所有操作复用这条连接。这样做的好处是服务端能记住“这个 socket 对应哪个用户”不用每个请求都重新鉴权坏处是 TCP 是字节流没有消息边界一次readyRead可能收到半个报文也可能收到两个半报文粘在一起这就是常说的粘包。处理办法很直接自定义一个定长头头里带负载长度接收端维护一个按 socket 区分的缓冲区循环判断“缓冲区里够不够一个完整报文”。代码放在第 4 章展开。这里先记住一个原则报文头要尽可能短但要包含一个魔数用于快速识别协议、一个类型字段用于分发、一个长度字段用于切包。多字节整数在网络传输时最好统一字节序项目里用qToBigEndian转换避免大小端机器混连时读出天文数字。2.3 C/S 职责划分客户端只管界面服务端只管落盘架构上客户端和服务端的边界划得很清楚。客户端负责三件事渲染笔记列表和编辑器、把用户操作编码成报文发出去、把服务端返回的结果解析成界面状态。服务端负责四件事维护用户表、校验登录、按用户名定位目录做文件读写、把处理结果回写给对应 socket。数据库交互在这个项目里被文件读写替代这个取舍第 3 章细讲。这种划分带来的直接好处是客户端可以做得很薄换一套界面比如换成 Qt Quick不影响服务端服务端也可以独立部署到一台内网机器上客户端通过配置里的 IP 和端口连过去。我在类似项目里一般会把协议定义单独抽成一个静态库客户端和服务端都链接它这样报文结构体只写一份改字段时两边一起重编不会出现“客户端发 8 字节头、服务端按 12 字节解析”的低级错误。工程用 CMake 管理一个顶层CMakeLists.txt同时产出服务端、客户端和一个公共协议库cmake_minimum_required(VERSION 3.16) project(CloudNote LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_AUTOMOC ON) # 让 Qt 的 moc 自动处理带 Q_OBJECT 的类 find_package(Qt6 REQUIRED COMPONENTS Core Widgets Network) # 协议与存储逻辑抽成静态库客户端服务端共用避免结构体定义漂移 add_library(note_core STATIC src/common/protocol.cpp src/common/storage.cpp ) target_include_directories(note_core PUBLIC src) target_link_libraries(note_core PUBLIC Qt6::Core Qt6::Network) add_executable(note_server src/server/main.cpp src/server/NoteServer.cpp ) target_link_libraries(note_server PRIVATE note_core Qt6::Network) add_executable(note_client src/client/main.cpp src/client/MainWindow.cpp src/client/LoginDialog.cpp ) target_link_libraries(note_client PRIVATE note_core Qt6::Widgets Qt6::Network)这段配置里几个点值得说明。CMAKE_AUTOMOC ON必须开否则带Q_OBJECT宏的类编译时会报 vtable 未定义note_core用PUBLIC把src目录导出客户端和服务端都能直接#include common/protocol.h服务端只链接Qt6::Network不链接 Widgets这样部署到没有图形环境的服务器上不会因为缺 GUI 依赖启动失败。参数上CMAKE_CXX_STANDARD 17是为了用上std::optional、结构化绑定这类写起来顺手的东西Qt 6 本身也要求 C17 起步。提示如果手头是 Qt 5.15把find_package和target_link_libraries里的Qt6::换成Qt5::即可其余代码基本不用动但QRegExp这类 Qt 5 遗留类不要用直接上QRegularExpression方便以后迁移。编译顺序上建议先编note_server再编note_client前者能独立启动并监听端口后者启动时如果连不上会弹连接失败提示方便确认服务端是否真的在跑。三个平台各自执行cmake -B build -DCMAKE_PREFIX_PATHQt安装路径然后cmake --build buildWindows 上如果用的是 MSVC记得把 Qt 的 bin 目录加进PATH否则运行时会缺 dll。3. 存储层与目录结构拿文件系统当云端数据库这个项目最容易被低估的部分是存储。它没有引入 SQLite 或者 MySQL所有数据都落在服务端一个根目录下用户信息一个 txt每个用户一个子目录笔记标题一个 txt笔记正文一个文件。这种设计的移植性极好把整个目录拷走就是一次完整备份用tar打包就能迁移到另一台机器代价是并发控制和查询能力都得自己写索引文件一旦和实际文件不同步就会出现“列表里有、点开是空”的尴尬。理解这套目录约定是后面改代码的前提。3.1 服务端目录布局与各文件职责根目录下大致是这样一棵树noteserver/ ├── noteserveruser.txt # 全站用户表一行一个用户名|密码 └── users/ ├── alice/ │ ├── booklist.txt # 该用户的笔记标题索引一行一个标题 │ └── book/ │ ├── 周会记录.txt │ └── 读书笔记.txt └── bob/ ├── booklist.txt └── book/noteserveruser.txt承担用户表职责每行用固定分隔符存用户名和密码。真实项目当然不会明文存密码这里为了演示简化了二次开发时第一件事就是换成加盐哈希。users/用户名/booklist.txt是这个用户所有笔记标题的索引客户端登录后拉取列表其实就是把这个文件读出来按行拆分。book/目录下每个.txt文件对应一篇笔记文件名就是标题。这种“索引和内容分离”的做法在文件数不多时很方便列表读取不用遍历整个目录但索引和目录必须严格同步重命名、删除时两边都要动。3.2 保存一篇笔记先落内容再写索引保存是最核心的写路径逻辑不复杂但顺序不能反。如果先写索引再写文件中间进程崩了就会留下一个指向不存在文件的标题反过来先写文件再写索引最坏情况是文件存在但列表里看不到用户重新保存一次就能修复。代码大致如下// storage.cpp bool Storage::saveNote(const QString user, const QString title, const QByteArray content) { QDir userDir(m_rootPath /users/ user); if (!userDir.exists() !userDir.mkpath(.)) { return false; // 用户目录不存在且创建失败直接返回 } QDir bookDir(userDir.filePath(book)); if (!bookDir.exists() !bookDir.mkpath(.)) { return false; } // 1. 先写正文Truncate 保证覆盖旧内容而不是追加 QFile noteFile(bookDir.filePath(title .txt)); if (!noteFile.open(QIODevice::WriteOnly | QIODevice::Truncate)) { return false; } if (noteFile.write(content) ! content.size()) { noteFile.close(); return false; // 写入不完整视为失败 } noteFile.close(); // 2. 再更新索引已存在则不重复追加 return appendTitleIfAbsent(user, title); } bool Storage::appendTitleIfAbsent(const QString user, const QString title) { QString listPath m_rootPath /users/ user /booklist.txt; QFile listFile(listPath); if (!listFile.open(QIODevice::ReadWrite | QIODevice::Text)) { return false; } QStringList titles QString::fromUtf8(listFile.readAll()).split(\n, Qt::SkipEmptyParts); if (titles.contains(title)) { return true; // 标题已存在不重复写 } listFile.seek(listFile.size()); // 定位到末尾追加 listFile.write((title \n).toUtf8()); return true; }saveNote的两个参数之外还有一个隐藏前提title必须已经做过非法字符过滤不能包含/、\、..这类会跳出用户目录的片段。参数content用QByteArray而不是QString是因为笔记内容可能是任意 UTF-8 文本甚至未来扩展成带图片的二进制用字节数组更通用。appendTitleIfAbsent里用Qt::SkipEmptyParts过滤空行避免文件末尾多一个换行导致列表里出现空标题seek(size())是追加写的关键直接WriteOnly打开会把原索引清空这是新手最容易踩的一个坑。3.3 重命名与删除索引和文件必须同进同退重命名的语义是“标题变了内容不变”。实现上要依次做三件事把book/旧标题.txt重命名成book/新标题.txt、把booklist.txt里的旧标题替换成新标题、如果新标题已存在则拒绝操作。第三步经常被漏掉结果用户重命名成一个已有名字两个索引项指向同一个文件删一个另一个也跟着没了。bool Storage::renameNote(const QString user, const QString oldTitle, const QString newTitle) { QString base m_rootPath /users/ user; QFile oldFile(base /book/ oldTitle .txt); QFile newFile(base /book/ newTitle .txt); if (!oldFile.exists()) return false; if (newFile.exists()) return false; // 目标已存在拒绝覆盖 if (!oldFile.rename(newFile.fileName())) return false; // 文件改名成功后再改索引这里失败会导致索引与文件不一致 QStringList titles readTitleList(user); int idx titles.indexOf(oldTitle); if (idx 0) return false; titles[idx] newTitle; return writeTitleList(user, titles); // 整表重写简单但要注意原子性 }删除则相反先清空文件内容再删文件最后从索引里移除标题。原文里提到“先将笔记内容清空再将标题从文本中去除”实践上直接QFile::remove更干脆清空这一步更多是给误删留一点恢复余地。writeTitleList用整表重写而不是逐行替换是为了避免不同长度标题替换时残留字节整表重写要配合临时文件加rename才具备原子性否则写到一半断电索引就废了。注意文件存储方案下所有写操作都应该假设“随时可能被打断”。我一般会在Storage里加一个QSaveFile的封装用于索引写入它自带写临时文件再替换的语义比裸QFile稳得多。4. 核心模块拆解协议帧、登录鉴权与笔记 CRUD真正把客户端和服务端粘起来的是协议层。这一层设计得好后面加功能只是加一个消息类型设计得糙每个新需求都要在收发两端各改一遍字符串解析。项目里的做法是定义一个固定 8 字节头加变长负载的结构所有业务操作都走同一套收发函数服务端按类型字段分发到对应的处理函数。这一章按“报文怎么切、登录怎么验、增删改查怎么走”的顺序拆。4.1 自定义报文格式与粘包处理报文头结构定义在公共头文件里客户端和服务端链接同一份// common/protocol.h #pragma once #include QtGlobal // 网络字节序统一为大端本地结构体只做内存布局不直接 memcpy 上线 struct FrameHeader { quint16 magic; // 0x4E54即字符 NT用于快速识别本协议 quint8 type; // 消息类型1登录 2列表 3读取 4保存 5重命名 6删除 quint8 reserved; // 预留用于以后加压缩标志或版本号 quint32 length; // 负载字节数不含头本身 }; enum MsgType : quint8 { MsgLogin 1, MsgList 2, MsgRead 3, MsgSave 4, MsgRename 5, MsgDelete 6, MsgRespOk 100, // 通用成功响应 MsgRespFail 101 // 通用失败响应负载里带错误描述 };服务端收到数据后不能假设一次readyRead就是一个完整报文必须缓存并按长度切// server/NoteServer.cpp void NoteServer::onReadyRead() { QTcpSocket *sock qobject_castQTcpSocket *(sender()); if (!sock) return; QByteArray buf m_recvBuffers[sock]; buf.append(sock-readAll()); while (buf.size() static_castint(sizeof(FrameHeader))) { FrameHeader hdr; memcpy(hdr, buf.constData(), sizeof(hdr)); hdr.magic qFromBigEndian(hdr.magic); hdr.length qFromBigEndian(hdr.length); if (hdr.magic ! 0x4E54) { // 魔数不对说明流已错位断开重连 sock-disconnectFromHost(); return; } int total static_castint(sizeof(hdr)) static_castint(hdr.length); if (buf.size() total) break; // 半包等下一次 readyRead 再拼 QByteArray payload buf.mid(sizeof(hdr), hdr.length); buf.remove(0, total); // 消费掉已处理的完整报文 dispatch(sock, hdr.type, payload); } }这段代码的关键在循环条件。外层while保证缓冲区里至少有一个头内层if (buf.size() total) break保证负载没收全就退出等待。qFromBigEndian必须在memcpy之后调用因为 memcpy 只是复制内存不做字节序转换。缓冲区用QHashQTcpSocket*, QByteArray按连接隔离disconnect信号触发时要把对应条目删掉否则 socket 销毁后哈希表里留着野指针。4.2 登录与用户信息校验登录报文负载用简单的用户名\n密码拼接服务端按行拆开去noteserveruser.txt里比对。校验通过后把用户名和 socket 的对应关系存进QHashQTcpSocket*, QString后续所有操作都靠这张表识别“当前是谁在请求”不再要求客户端每次带用户名。void NoteServer::handleLogin(QTcpSocket *sock, const QByteArray payload) { QStringList parts QString::fromUtf8(payload).split(\n); if (parts.size() ! 2) { reply(sock, MsgRespFail, bad login format); return; } QString user parts.at(0).trimmed(); QString pass parts.at(1).trimmed(); QFile f(m_dataRoot /noteserveruser.txt); if (!f.open(QIODevice::ReadOnly | QIODevice::Text)) { reply(sock, MsgRespFail, server storage unavailable); return; } bool ok false; while (!f.atEnd()) { QString line QString::fromUtf8(f.readLine()).trimmed(); QStringList kv line.split(|); if (kv.size() 2 kv[0] user kv[1] pass) { ok true; break; } } f.close(); if (!ok) { reply(sock, MsgRespFail, wrong user or password); return; } m_sessions[sock] user; // 绑定会话后续请求不再重复认证 reply(sock, MsgRespOk, user.toUtf8()); }m_sessions这张会话表是服务端做权限判断的唯一依据所以它必须在disconnected信号里清理掉同时也要处理“同一账号多处登录”——项目需求里明确允许一个账号多端同时在线所以这里不能用QHashQString, QTcpSocket*反向去重得允许多个 socket 映射到同一个用户名。参数上的trimmed()不能省Windows 客户端发来的文本可能带\r\n不处理会导致密码比对永远失败这是跨平台联调时很典型的翻车点。4.3 笔记增删改查的完整链路CRUD 四个操作在协议层是四个类型在服务端是四个处理函数在客户端是四个界面动作但底层的收发函数是同一套。以“保存”为例客户端把标题和正文用\n拼起来标题不允许含换行正文可以服务端拆出第一行作为标题剩余部分作为正文void NoteServer::handleSave(QTcpSocket *sock, const QByteArray payload) { QString user m_sessions.value(sock); if (user.isEmpty()) { reply(sock, MsgRespFail, not logged in); return; } int sep payload.indexOf(\n); // 第一个换行之前是标题 if (sep 0) { reply(sock, MsgRespFail, bad note payload); return; } QString title QString::fromUtf8(payload.left(sep)).trimmed(); QByteArray content payload.mid(sep 1); if (title.isEmpty()) { reply(sock, MsgRespFail, empty title); return; } // 标题过滤拒绝路径穿越和 Windows 保留字符 if (title.contains(/) || title.contains(\\) || title.contains(..)) { reply(sock, MsgRespFail, illegal title); return; } bool ok m_storage.saveNote(user, title, content); reply(sock, ok ? MsgRespOk : MsgRespFail, ok ? QByteArray(saved) : QByteArray(save failed)); }读取链路反过来客户端发MsgRead加标题服务端从book/标题.txt里读出字节原样返回列表链路发MsgList服务端读booklist.txt整份回传客户端按行拆成QListWidget的条目。删除和重命名在第 3 章已经给过存储层实现服务端处理函数只是多了一层会话校验和标题合法性检查。整套链路里最容易出问题的是“客户端发完请求等响应”的时序如果界面上的保存按钮不做防抖用户连点两下就会发出两个MsgSave服务端处理两次第二次可能和第一次交错写同一个文件。提示客户端侧我一般在点击后立刻禁用保存按钮收到MsgRespOk或MsgRespFail再恢复配合 3 秒超时定时器避免界面卡在“保存中”。5. 多端联调与避坑排查并发写、中文路径和断线重连三个平台同时登录的测试场景是这个项目最容易暴露问题的地方。原文里用测试程序在服务端 Debug 输出里打印每个客户端操作来确认收包和执行顺序这个土办法其实非常有效比抓包工具轻量。实际联调时先起服务端看它打印“listening on 0.0.0.0:端口”再依次在三台机器上启动客户端每个操作都对照服务端日志确认“收到—处理—回写”三步都发生过。下面几条是这类项目里反复出现、且很容易被“本机测试通过”掩盖的坑。5.1 坑一两个客户端同时保存同一篇笔记内容互相覆盖现象是 A 机器改完保存B 机器紧接着保存旧内容A 的修改在列表刷新后消失。原因在于文件写没有并发控制两个QTcpSocket的handleSave在同一个事件循环里串行执行但谁后执行谁就把前面的内容整个Truncate掉而客户端界面上并没有“内容已被别人改过”的提示。解决分两层服务端在Storage里对同一用户的写操作加QMutex保证单次写入的完整性更彻底的做法是给每篇笔记加一个递增的版本号保存时带上客户端持有的版本号不一致就返回冲突让用户选择覆盖或另存。版本号方案在二次开发那章展开。5.2 坑二中文标题在 Windows 客户端建完Linux 服务端列不出来现象是 Windows 上新建“周会记录”客户端能看到换 Ubuntu 登录后列表里是乱码或者干脆没有这一项。原因是 Windows 下QFile接受的QString走的是 UTF-16而 Linux 下文件系统按字节存名字如果代码里某处用了toLocal8Bit()而不是toUtf8()两边落盘的文件名字节就不一样。解决方式是全链路统一 UTF-8协议负载、文件内容、文件名拼接全部用toUtf8()和QString::fromUtf8()禁止出现toLocal8Bit。另外 macOS 的文件系统对 Unicode 做 NFD 分解同一个“é”在 macOS 上存成两个码点跨平台比对标题时要先做QString::normalized(QString::NormalizationForm_C)。5.3 坑三客户端强制退出后服务端会话表里留着僵尸 socket现象是用户直接关窗口或者拔网线服务端m_sessions里那条记录还在下次同一账号登录时行为异常比如列表返回的是旧连接的数据。原因是disconnected信号在某些异常断开场景下触发有延迟代码里如果只在handleLogin里覆盖m_sessions[sock]旧 socket 指针可能已经被复用。解决是给QTcpServer的newConnection里创建的每个 socket 连接disconnected到onSocketGone在里面m_sessions.remove(sock)并sock-deleteLater()同时开启 TCP keepaliveQAbstractSocket::LowDelayOption配合系统级 keepalive 参数让死连接在几分钟内被内核回收。5.4 坑四重命名后 booklist.txt 和 book 目录不同步现象是重命名成功列表里显示新标题但点开是空白或者旧标题还能搜到。原因是renameNote里文件改名成功、索引重写失败或者反过来中间没有回滚。这个问题在正常路径下不会出现只有在磁盘满、权限不足、进程被杀时暴露。解决是引入“索引重建”兜底服务端启动时扫描每个用户的book/目录和booklist.txt做一次差集把缺失的标题补进索引、把指向不存在文件的标题剔除。这个扫描放在启动阶段代价可接受也能顺便修掉用户手动往目录里拷文件造成的不同步。5.5 联调时的观察顺序建议按“服务端日志 → 客户端状态 → 落盘结果”三层排查先在服务端每个dispatch入口打一行qDebug() sock type payload.size()确认报文类型和长度符合预期再看客户端收到响应后界面状态有没有更新最后去数据目录ls一遍确认文件真的写下去了。三层里任何一层对不上问题范围就缩小到那一段比漫无目的地读代码快得多。我一般还会准备一个命令行小客户端用nc或者几十行 Qt 代码手工拼一个登录报文发过去用来区分“是客户端界面没发出去”还是“服务端没处理”。6. 二次开发把文件存储换成 SQLite顺手加上版本号这个项目最值得动手改的地方是存储层因为它被Storage类封装得比较干净换实现不影响协议和界面。我的做法是保留文件存正文把索引和用户表迁到 SQLite建三张表users(id, name, pass_hash, salt)、notes(id, user_id, title, version, updated_at)、note_body(note_id, content)正文仍然可以按notes.id命名存文件也可以直接进 BLOB 字段。迁移时先写一个一次性脚本扫描现有目录把booklist.txt和book/*.txt灌进库跑通之后再删旧索引文件。版本号是第二个要加的字段。客户端读取笔记时把version一起拿回来保存时带上这个值服务端执行UPDATE notes SET version version 1 WHERE id ? AND version ?受影响行数为 0 就说明有人先改了返回冲突码让客户端提示“内容已更新是否覆盖”。这比加锁简单也不会阻塞多端同时编辑不同笔记。// 迁移后的保存逻辑乐观锁冲突时返回 false 由上层提示 bool NoteRepo::saveWithVersion(int noteId, int baseVersion, const QByteArray body) { QSqlQuery q(m_db); q.prepare(UPDATE notes SET version version 1, updated_at ? WHERE id ? AND version ?); q.addBindValue(QDateTime::currentDateTimeUtc()); q.addBindValue(noteId); q.addBindValue(baseVersion); if (!q.exec() || q.numRowsAffected() 0) { return false; // 版本不匹配或 SQL 失败都按冲突处理 } // 正文单独写失败时依靠事务回滚保证 version 不会虚增 QSqlQuery bodyQ(m_db); bodyQ.prepare(UPDATE note_body SET content ? WHERE note_id ?); bodyQ.addBindValue(body); bodyQ.addBindValue(noteId); return bodyQ.exec(); }验证方法很简单开两个客户端读同一篇笔记A 先保存B 再保存B 应该收到冲突提示而不是静默覆盖。这条链路跑通之后再把增量同步加上去——客户端本地记录上次同步时间登录时只拉updated_at大于该时间的笔记摘要笔记数量上去之后列表加载会明显变快。从那以后我每次给这类小项目加存储层都会先把“索引和正文分开、写操作带版本号、启动时做一次一致性扫描”这三件事定下来再动手写界面不然等到多端联调时才发现数据对不上返工的成本比一开始多写两百行代码高得多。希望帮到你。本文还有配套的精品资源点击获取