如果有云端同步（官方 orS3），可直接同步

如无，先导出一份 data，再升级

如果自定义 CSS+JS 比较多，谨慎升级，可能造成 bug 冲突

如果没有特别多自定义代码，可升级

可以综合上述四种情况考虑

目前本人所碰到的问题都是思源和自定义代码的冲突，思源本身更新比较稳，有小问题也修得快（但如果和自己的代码有冲突，这就是自己这方面的问题，比较麻烦），供参考

​

超链接样式：

[data-light-theme=Savor] .protyle-wysiwyg [data-node-id] span[data-type~=a], [data-light-theme=Savor] .protyle-wysiwyg a,
[data-dark-theme=Savor] .protyle-wysiwyg [data-node-id] span[data-type~=a], [data-dark-theme=Savor] .protyle-wysiwyg a {
color: #FFFACD;
text-decoration: none;
}

先尝试一下这段 CSS【设置-外观-代码片段——新建 CSS】，看下可否变色

如果生效，就会是下图效果

这问题我都没想到过，原来这个是可以解决的，感谢，哈哈哈

systemlog.zip

感谢大大，今天刚同步了一个新的工作空间，不知道哪里出问题了 😂

大大，感觉实在很难找到合适的十四种颜色，一要明暗色值更替符合逻辑，二要七种各自适合黑白主题的易读，三要保证黑白主题下各自的七种颜色还尽量避免混淆

我给的建议是，如图选取这种中间带色值，共七种，使其在黑白主题下都比较易读。

当然，这个的问题是，这些颜色就比较中庸保守，不能说好看了（俺的审美），而且对红绿色盲可能不太友好，因为“now”和“喜欢”颜色非常接近（其实“喜欢”可以改成紫色，可是更丑，而且对应的通用意义就不太正确——喜欢怎么会是紫色呢？？？）不过论及实用性应该是更强的

另一种，就是白天选用这个方案，而夜间还是我之前给的夜间方案（我个人觉得这两个方案在黑白颜色下的过渡相对来说有点逻辑，可也感觉不是最完美的方案，头秃）

白天主题下（如上图）的色值方案

"orangeRed": { style: "color:#cc0000", description: "NOW" },
"yellow": { style: "color:#B8860B", description: "重要" },
"teal": { style: "color:#00796b", description: "完成" },
"blueDark": { style: "color:#1a73e8", description:"TODO" },
"gray": { style: "color:#4a5568", description: "PASS" },
"pink": { style: "color:#FF2D55", description: "喜欢" },
"orange": { style: "color:#c25700", description: "特别" }

给出另一个灵感给大大，不过我不清楚能否做到，这个可能需要修改更多代码

即，相较于更改明暗两种主题下的字体颜色（这个一旦涉及到自定义背景图片之类的，其实也不太好用）

更好的视觉方案，实际是文字背景色，即如图

理想效果应当是如图中蓝圈部分

• 第一种——

整个文档标题都赋予背景色

背景色怎么都可以调，这个色块比较大，只要颜色合适，就不怎么需要调整夜间和白天主题，只需要确定这个背景色就可以了

• 第二种——

则如第一张图中的黄色荧光圈位置，只要这个部分增添背景色就可以。

但我找到的 CSS，就只能修改为如图中红圈所示部分，这个遮挡了右边的三个小点和“＋”号。

如果不增添背景色的话，白天模式下的自定义颜色应当较深，而夜间模式下自定义颜色应当较浅，我之前所做的，确实是只跟着我那套自定义主题来着 ^_^

然而，我还是倡导，最好不要区分夜间和白天两种颜色主题，假设以我所给的七种颜色定义做参考，白天的红不是夜间的红，白天的蓝不是夜间的蓝，如果不好好区分色彩的话，大脑可能将白天和黑夜的相近颜色弄混，那么使用者就得记 14 种颜色的定义（这个虽说不难但有点复杂）【还是说，大大的 JS 所赋予的文档标题颜色，将可以根据黑白主题自动切换呢？有点没看懂】

回答大大的建议，这里给出一份颜色方案（说是如此，其实也就是更改了下颜色定义而已，当然，这里是我的习惯，相较颜色颜值，个人认为颜色的意义更重要）

红色 now （红色给人感觉最紧张，一旦标注为红色，从潜意识上将会催促人赶紧改变 or 消灭这个“红色”）
黄色 重要 （黄色也会造成一定视觉刺激，但不具备红色的危险性，虽说如此，黄色标注也不该过多，否则就会失去焦点）
绿色 完成（这个越多越好，很有成就感）
蓝色 任务 TODO（比较冷静的颜色，用于规划 思考 任务 之类的较为耗费意志力的活动时，给人的心理压迫最小）
紫色 特别（注意-其他，这个颜色在自然界中很少见，在各行各业的使用场景也比较少，一旦发生就是比较特别的东西）【我给的色彩方案改成了橙色，原因是，我个人感觉同色系的紫色和粉色很相近，容易混淆】
灰色 pass （不是“delete”，而是更像 later 处理）
粉色 喜欢 收藏（为什么会喜欢某个文档呢？哈哈，可能这个文档实际是自己的精华笔记之类的，这个按我的用法，一般也会标注较少，而是用爱心图标取代颜色）

• 文档靠颜色赋予某种含义，在这个 JS 的使用场景下，最好避免使用多彩文档树，否则就无法发挥这个“颜色的定义功能”
• 颜色也不宜过多，一来将会造成选择困难症，二来文档颜色过多过杂也失去筛选的标注意义，三来颜色越多，其对应的意义就越多，则越难记住
• 给文档标注颜色，这个功能的本质就是“给某些文档定义属性”，“属性”作为架构底层的信息设计，应当越简单越容易被记住——
  举个例子，就好比读纸质书时用彩笔标注，如果拿一整盒水彩笔去画线，那满篇的花花绿绿基本上也没啥意义了。

知乎给的这份颜色表大致看起来就挺不错的，不用怎么改了，我主要是改了下“蓝色”数值，它原来的那份颜色太深不易读。

"orangeRed": { style: "color:#e6194B", description: "NOW" },
"yellow": { style: "color:#ffe119", description: "重要" },
"teal": { style: "color:#469990", description: "完成" },
"blueDark": { style: "color:#87CEEB", description: "TODO" },
"gray": { style: "color:#778899", description: "PASS" },
"pink": { style: "color:#fabed4", description: "喜欢" },
"orange": { style: "color:#f58231", description: "特别" }

改了下“特别”的 css，变成这种渐变色

大大，有个奇怪的问题，应当不是 bug，只是有种奇怪的联动感，这个让我很迷惑……

如图，实际上在大多数情况下，我应当不会给文件夹赋予颜色（靠图标来区分文件夹属性），而是给文档赋予颜色。

因此，我一直将二级文档树（集市有二级文档列表这个插件）的 dock 部件固定在右边，目前大大你给的 JS 片段在思源原生文档树上的操作没有问题（我没有碰到其他题主的 bug，因为我用的是 Asri，最开始那个版本就可以用），奇怪的地方在于——

当我用了 0.0.4 这个更新后的 JS 片段后，某一个瞬间，二级文档树的右键菜单里忽然也可以直接更改文档颜色片段（之前是不可以的），然而这个事只发生了一次，之后我再在二级文档列表里调用右键菜单时，就再也没有看到过这个“更改文档颜色”选项。

我好奇的是，大大的这个 JS 片段是可以影响到二级文档树列表的吗？还是说这反而是我操作时无意发生的某种 bug？

另一个关注的点是，我很希望这个功能主要是发生在“二级文档树”上（原因如前，文件夹并不需要赋予太多颜色 😂 )，这个也可以通过请求开发“二级文档列表”这个插件的大大做到跟您差不多的效果吗？还是说，大大你的这个 JS 片段本来就可以融汇到“二级文档列表”右键菜单的吗？

凡是可以优化文档树的我都支持，谢谢大大

集市有个“列出子文档”挂件（不是插件）应该可以满足这个需求

没人回复时就可以删除，比如你这个帖子，因为现在有人答复就不能删除了 ^_^

楼主是不是想说数据库的某个条目？

——“关联”这个类型，可以去试试（这个条目类型的概念比较抽象，就是关联另一个数据库，可能需要多找点资料了解下）

ac 娘.7z

感谢大大，就是这个，我找到的是 png 格式，acfun 还有一种是 eif（这种好像是专门给 qq 微信输入法用的——这个需要吗？）

深有同感。

楼主的重点是“AI 根本就没吹嘘得那么好用”由此引申出“新闻学的不可靠”（这点可就复杂了，作为个人来说，别什么都信什么都听就是了），我这里补足另一个观点就是——

有些路是不能绕捷径的。

即整理笔记也是学习的一个环节，AI 可以辅助排版可以辅助查找相关内容，唯独不能替代人本身去整理笔记。

因为不做这个动作，就会削弱大脑对笔记的思考，也就无法开启“深度学习”。

针对笔记软件中悬浮目录功能的优化方向，可以从以下多个维度进行深入改进，提升用户体验和效率：

这个是 AI 所写，个人感想使用【】

一、交互体验优化

1. 动态折叠与智能展开

   • 层级感知折叠：根据用户当前阅读位置（如标题层级），自动折叠非相关层级目录（如仅展示当前章节的 2-3 级标题）。【这个看动图好像可以做到】
   • 手势交互：支持双指捏合展开/折叠目录层级，长按目录项直接拖拽调整文档结构。【这个涉及到的知识是不是有点难？？？二级文档树到现在都没法自由拖动排序，可能就是这个原因】
   • 焦点跟随：滚动正文时，悬浮目录自动高亮并居中显示当前章节，同时折叠非相邻章节。【这个感觉比较好用】

2. 快捷操作集成

   • 右键菜单增强：在目录项右键添加「跳转到子标题」「复制标题链接」「快速拆分/合并章节」等高频操作。【这个在我看来，似乎有点繁琐，不过如果加上好像也挺好用，但这应当是个很大的工作量】
   • 拖拽多选：支持框选或 Shift 多选目录项，批量调整章节顺序或层级（类似文件管理器逻辑）。【这个背后原理不太懂，也许很难？？？它这个和文档树有点类似，选了目录就直接调动整个文档界面的内容，这个真的有必要吗？？？这种使用频率似乎不够高……】

二、视觉与信息呈现优化

1. 三维视觉反馈

   • 深度指示：通过阴影、缩进层级和颜色渐变区分标题层级（如一级标题深色加粗，次级标题逐渐淡化）。【UI 方面的，这个感觉不错】
   • 阅读进度可视化：在目录项右侧添加细进度条，显示该章节的阅读完成比例（通过文字密度分析估算）。【思源可以联动到这份上吗？估计也不容易】

2. 动态内容预览

   • Hover 卡片：鼠标悬停目录项时，弹出缩略图或关键句预览，避免频繁跳转。【感觉复杂，悬浮需求有必要吗？如果可以开发出来可能会好用，但可能会影响思源性能，造成卡顿，这是我的揣测】
   • 关联标签：自动标记含图片、表格、代码块的章节，通过图标直观展示内容类型。【同上】

三、功能增强

1. 智能目录管理

   • 自动语义重组：通过 NLP 识别内容主题，建议合并/拆分章节（如检测到连续多个短段落讨论同一主题时提示合并）。【复杂】
   • 版本对比：记录目录结构历史版本，支持与早期版本对比并恢复。【这个感觉很没必要，然而这个真是 AI 才能提出来，一般使用者想不到这个】

2. 跨文档联动

   • 多文档目录聚合：在协同场景下，悬浮目录可同时显示多个关联文档的目录（如项目文档 + 会议纪要），支持跨文档跳转。【这个是啥？有点不懂】
   • 书签同步：将目录项与文档内自定义书签绑定，实现混合导航。【无法想象，从来没有见过哪个目录导航能做到这份上，但不明觉厉】

四、场景化适配

1. 创作模式优化

   • 大纲模式融合：进入写作模式时，悬浮目录自动切换为可编辑大纲，支持直接修改标题文本或升降级。【这个感觉不错，不过话说回来，感觉工作量不小】
   • 思维导图联动：点击目录项右侧图标，一键生成以当前章节为中心的局部思维导图。【同上】

2. 移动端专属设计

   • 摇杆式导航：在窄屏下将目录转换为底部半屏摇杆，滑动控制滚动速度，点击快速定位。【不懂】
   • 语音导航：支持语音指令如「跳转到第三节」「展开所有二级标题」。【感觉这个是真鸡肋】

五、性能与底层优化

1. 实时响应机制【这个是给开发者的建议，不说了】

   • 增量加载：超长文档中仅渲染可视区域目录项，滚动时动态加载（类似虚拟列表技术）。
   • 差异更新：通过 Diff 算法仅更新变动的目录节点，避免整体重绘导致的卡顿。

2. 智能预判

   • 滚动惯性预测：根据滚动速度预加载即将到达的目录节点，确保流畅的高亮切换。

六、用户自定义体系

1. 个性化规则引擎
   • 条件过滤：设置「自动隐藏所有空章节」「仅显示含 TODO 标签的节点」等自定义过滤规则。
   • 样式模板库：提供不同场景的目录主题（如学术论文模式、会议记录模式），支持导出分享。

示例方案：智能写作助手模式

• 场景：用户撰写技术文档时，悬浮目录右侧常驻 AI 面板：【这个是接入了 AI 的目录，和现在大大做的目录，不是一回事啊，同理，感觉这个不容易做到】
  1. 自动检测「缺少结论段」并红色警示
  2. 推荐插入「代码示例」「流程图」等模块按钮
  3. 实时显示章节字数统计与建议优化点（如「当前段落术语密度过高」）

通过以上优化，悬浮目录可从被动导航工具升级为主动创作助手，同时兼顾效率型用户的深度需求和新手用户的易用性。建议采用 A/B 测试逐步推进，优先落地高 ROI 功能（如目录搜索、拖拽调整），再迭代智能功能。【这个应该是给开发者的建议，ROI 这种术语都出来了，哈哈哈】

用不用取决于使用者，开不开发取决于开发者。

使用者对开发者所做的某个非强制不影响使用体验的功能缺乏感知，就是楼下这种了。

很多开发者做某个东西，最开始都是基于自己的某些目的，有的是练手，有的是自用，有的是为爱发电，大大感觉有必要就做吧，真正在需要者的使用场景里，还是相当实用滴。

有句糙话是，我可以不用，你不能没有（捂脸），大概就是这种情况。关键是看大大的动图，已经做到一定可用性了，做好了之后一定会有人需要的。👍

这个很棒啊，感谢大大。就我的理解，这个设计是不是和 ob 的 floating index（好像是这个）插件相似？就是可以使大纲悬浮起来——就动图与说明看起来，似乎是这个样子？

（我就说嘛，ob 能做到的东西，思源大差不差也都能做到类似的，就是这边开发者人手缺乏罢了，扼腕……）

这个我所能想到的第一个优点就是节省面板位置，因为插件那么多，而软件本体除了编辑器之外的其他部分又那么小，可谓寸土寸金，参考我的话，左边是自带文档树 + 书签两个部件，右边是二级文档树这个部件，这三个是长期固定，常用的浮动面板是 knote 和小记，偶尔需要查看大纲，就得按快捷键切换了（因为不是每个文档都有大纲，需要用的时候才会固定，不用的时候就不希望它占用位置）

因为文档跳转频繁，文档树与其浮动还是贴边吧，而浮动的大纲面板可以按照需要跳出来，最能辅助正文查看又能灵活调取（不至于总是放在某个地方），唯有它浮动起来是最合适的 😁

我的体验是，它是一个有则最好，无则稍憾（思源本体可以凑合）而绝非鸡肋的功能设计，ob，flowus（notion 不知道）还有有道云（印象不知道）这种都有特别给出这个设计啊，所以它绝对是有必要的

目前我所想到的优化方向，1 设计上，应该是这个面板先跟主题风格和谐一致，除此之外，2 这个 UI 的信息界面，大大要不要参考动图右边那个大纲插件设计？给每个大标题旁边都用数字标注其下小标题的数量之类的？

另，有道云的悬浮大纲，在不用时会变成一道道长短不一的横线，这个看起来很简洁，但可以的话，请大大千万别做成这样，因为我用过几次，每次都需要鼠标浮过去它才会显现，不够直观还增加了操作步骤。

也不希望完全参照 ob 的那个插件——只能在一个固定位置悬浮（这个当大纲标题太长时，偶尔会和正文重合起来），就是动图中这种自由拖动我感觉挺好的 👍（不过它是只能在编辑区拖动？还是可以在整个界面拖动呢？后者感觉更好一点）

其实这个面板，只要存在了就是它最大的意义，其他都是锦上添花（来自小白的看法）

再次强调。这套流程，绝对没法让碎片笔记保持整洁状态，相反，乃是以无序应对无序，表象看起来一定很乱，但提取效率相对最高，管理成本相对最低。

如果想让碎片笔记井井有条，整理美观……这套流程背道而驰，完全不可取。

简言之。碎片笔记，1 记录时就是无脑囤——虽说是无脑，既然选择囤起来，至少已经筛选过一遍，这内容有点用处。【输入】

2 囤积时，做好标注，重点是方便日后索引。【整理】做且只做这一个动作

3 只在需要某个内容时，和体系笔记配合起来，针对碎片笔记集中索引，其余情况，继续循环上述两步（无脑囤 + 标注）【输出？非也，笔记的目的是为了解决问题，即复用，输出成文只是复用的一个方式而已。】

最近的体会，以任务为导向来做笔记时，“做事感”非常丝滑，爽到飞起。

只是为了做笔记而做笔记，之后整理笔记都变成了一个任务，如果“整理笔记”这个动作，没有指向一个具体的有反馈的结果，那还不如不做。

思考与做事这两件事，比起“沉迷做笔记”这个事要重要得多。

但学无止境，很多知识/事件/经历不做笔记是不行的。

所以我现在的做法是——

一种是以研究某个课题为导向来做笔记

一种是以纯粹记录备忘来做笔记

前者一定是指向我想搞定的某个具体事情，后者则是 DN，记录每天值得记录的一点东西，让离去的每一天染上一点痕迹。

哇奥，这个是多么简洁优雅，非常好看啊 ❤️

我的卡片，因为我写东西排版太糙了，呈现出来是这种……

目前很好奇的是这个

列出子文档似乎没法做到这种效果？？只是普通文本引用而已。（看插件大佬的备注是，不要随便开启这个效果，否则有点不好用）

但图片中这个，与 trilim 的卡片设计细节更接近，可以说是一模一样了。

楼主，给你几个链接参考，你看一下可否满足你的需求。

【主题宣传】OneNote 主题回归思源 - 链滴

about 文档树的彩虹目录 - 链滴

多彩文档树 - 链滴

超级块光是要自己排版这一条，就感觉不 ok，trilium 这种排版是自动生成的，使用很丝滑

画廊模式，感觉更多是应用于“思维”领域，总不能把所有文档都放到数据库中去 😂

目前大家的答案中，最像 trilium 这个设计的，还真就是挂件“列出子文档”，在设置中修改模式为“预览方格”@mozhu - 链滴

要是能有快捷键直接切换就好了，这个每次都要自己加挂件，但观感很接近了哈哈哈

另一个问题：它这个能做成挂件，那是不是说它也能做成插件？做成插件，有这个可行性吗？做成插件，是不是就能用快捷键切换了？？

小声：其实俺一直觉得插件和挂件没啥区别 😂

话说，思源有二级树，我感觉这个卡片式样的设计，就是二级树的画廊模式啊，无论如何，挺好看的

obsidian 里面似乎也有类似的插件

大大，请问这个由段落块转变为嵌入块有什么语法吗？

ob 里面是！[[]]这种，将引用块转变为嵌入块

思源里，没有搜到类似的快捷键

补充楼下的，还有另外两种方法可供参考（只是目前你说的那种“置顶”功能，在文档树里只能手动置顶，狗头无奈，没有像传统笔记软件在右键选项里有“置顶”选项——这个可能是需要 js 动作就能实现？？？最开始是可能有点不习惯，用惯了就会发现这种置顶需求还有更优解）

第一种：用“pin”功能，在横向 tab 栏钉住文档（这可能算是一种置顶吧，弊端是 pin 多了，比较占 tab 栏的位置），将这个文档当做 moc 目录，选你觉得重要的文档复制引用块到里面就行了

第二种：用思源的“小记”插件，使其以 dock 形式常驻（即把那个小记面板调出来，让其常驻思源界面）

之后选择你需要的文档以“复制 md 超链接”的方式，在小记里创建 memo，一个 memo 卡片可以放置很多“引用文档”

建议 memo 卡片也加上标签辅助管理，但弊端也是类似，卡片多了，上下滑动起来可能也不容易找到

不过这个插件目前还在开发中（开发者大大在论坛），后续应该还会继续优化吧

我个人认为，在“书签”“pin”“小记”这三种方式中，最后一种“小记”用来当“索引 index”的潜质最大，因为它可以聚合最多内容，同时管理成本算是相对最低的（不过，如果不是重度需求，还真用不上这个，有点杀鸡焉用牛刀的既视感 😂 ）pin 和书签合起来就可以满足大部分需求了。

元思的最大优点是“卡片式的直观”，它和另一种“画廊”模式还不同，它是真的做到以双链把一张张小卡片链接起来了——这种设计的优势就是，卡片越多效果越好（也不需要整理）【它就是 lattics 那个卡片库之设计理念的移动版，哈哈哈】

然而思源的小记本体，估计不会发展成这个路线，它和思源联动起来，或许可以模拟一个超大号的元思？？？

本来都卸载元思小半年了，你说了之后我又重新去下载

元思是干货卡片，小记是便签，这就是我的分类了，元思可能是我之前用法不对（太花心了，那时候把 ob 思源 logseq 全部都用上，现在慢慢去繁求简），现在我才注意到它有一个 md 导出，以后做多卡片了，可以导出到思源来整理——然而保存的双链啥的就别想了

元思笔记，我是没有想到一个好用的复用机制，但它用来做干货卡，是最方便

感谢，这个关注好几天了，确实很有用。我也有差不多类似的需求，只是之前一直偷懒没有多想（懒到宁愿一直用文档树那个小折叠号，一直都这么麻烦），而且也描绘不清楚这个痛点究竟该怎么解决，800 分太壕了，感谢发帖的大大和回帖的大大 😄 造福一众小白啊哈哈

确实。元思笔记，这种设计用来做卡片体验很好。不过我习惯用手机端记录，pc 端整理，它的整理机制不是很好用……就这点，忍痛弃掉了。但，它才是那个真正符合“卡片笔记”（碎片化）的设计理念，flomo 或者小记，在我看来都是随便用来乱写的便签哈哈哈（微博段子式）

重点还是使用者的取舍 😄