非常感谢。目前先自己转 svg 贴上来。

D 大，能不能在 conf.json 里面提供一个配置项？不在界面里面也可以。修改 hosts 也不是可行选项，因为本地服务器不能开在 80 端口，工作系统上也不允许修改系统文件（包括 hosts）。某些离线环境太难了。

目前思源还是做个人知识管理系统，分享不是一个必选项，甚至都不是一个选项。如果需要分享，可以将笔记导出为 Markdown，或导出 HTML，建一个网页服务直接分享即可。相信既然能建网页端，那么建一个网页服务也是可以的。

感谢，已搞定。

@88250 求救

字体的设置问题说一点我的看法：

1. 真关心外观，学一点 CSS（其实只要能看懂并找到字体在哪里改即可），然后自己改一个主题，其实不会花很多时间，而且完全私人定制，控制感满满的。一般拿自己喜欢的主题，改 1-2 行，字体就搞定了。中英文字体名都能用，CSS 没要求只能用英文的。
2. 搜狗的做法，额，我只能说软件和软件不一样。好的软件让普通用户开箱即用，让高级用户完全定制，处于中间状态的用户，软件根据自己的实现复杂度来取舍。我理解思源在让普通用户开箱即用方面做得还是很不错的，让高级用户完全定制也非常棒，不过对中间态的用户照顾得少了一点。但考虑到只有两位开发者，其实这是非常合理的选择，我们作为用户也不必苛求。想要定制，就把自己变成高级用户呗，反正技多不压身。

如果这种问题总是出现的话，我感觉思源有必要重新启动基于 git 的历史保存了。

首先要确认这个文档的你要的版本还在不在，找个文本编辑器（notepad++ 就可以，实在懒的下载 notepad 也可以）打开 history 里面的 .sy 文件，一个一个地确认吧。找到了以后就好办了。我没试过，但应该可以直接用找到的 .sy 文件覆盖 data 目录里面的 .sy 文件。在做任何覆盖前记得备份整个 data 目录。

用 Python 写一个工具，读取 .sy 文件（其实是 json 文件），修改数据删除空白行和无价值段，然后写回 json 即可。python 自带 json 模块，连第三方依赖都省了。Python 很好学也很值得学，一举两得。数据库反倒麻烦一些，目前不知道数据库的大纲，需要自己的解析。

比较好奇这个如何实现？目前也就 Typora 有。

说几点看法和期望：

1. 如果关心修改历史，但又只关心文件名，这个只能说是“叶公好龙”。我不用思源的历史功能，也不用第三方同步的历史功能，自己建了一个 git 仓库，手工管理历史，清清楚楚。只要思源维持“本地 + 文本”这种技术路线，想要修改历史有无数种办法，为什么要纠结文件名？
2. 如果确实对 id 和文件名的对应关系有需求，在 sy 文件里面有，随便找个 json 解析工具一提取就搞定了，只是稍微费一点功夫而已。
3. 我们作为软件的用户，要区分软件的「内部实现」和「外部接口」的边界。简单地说，思源如何组织笔记文件、如何存储笔记数据，这个是软件的内部实现，本来就是会随软件发展不断变化的。但思源将笔记「按目录和文本文件组织为本地磁盘的数据」，这是软件给用户和开发者的保证，可以预期是不会急剧变化的，可以理解为是一种外部接口。我们搭建自己的工作流，要基于软件的「外部接口」而非「内部实现」。如果真要基于「内部实现」，就要做好持续跟随改变的准备，而不是不断给软件开发者提要求说「内部实现」变化不合理。
4. 期望思源笔记尽快梳理出一个稳定的开发接口，包括数据格式、数据存储、查询修改等，在能给出稳定预期的地方，尽量给出稳定预期，这样大家知道什么会变，什么不变，搭建工作流和开发额外工具也就比较放心。

经测试，使用 Google Chrome 确实正常了。

感谢。

现在的订阅数 x 订阅价格根本就支撑不住两位开发者，D 大和 V 姐目前都是情怀开发。如果觉得软件好用，满足了自己的需求，就付费支持一下呗。98 块比某象啥的已经非常良心了，数据也给你放本地完全自己控制，格式也是开放的，块链接机制和全文搜索对重度笔记简直就是神器，98 块简直太值了，两个人一顿饭钱而已。

感谢指出。确实那个列表在一个超级块中，不在超级块中的没问题。那个超级块是此前拖动重组列表的时候产生的，没处理干净。

目前思源只有 x86_64 版本的 docker 镜像。nas 是 arm 处理器吧？应该还不支持？期待官方答案。

在设置里面看看数学引擎是 KaTeX 还是 Mathjax，后者有这个毛病。

感谢 D 大。原来是移到这里了。

冒充开发者回复一下。

自动同步真的很难做好。由于思源支持多端修改 + 多端同步，就必然存在在系统 A 上和系统 B 上同时修改笔记 C 的情况，这就是一种「修改冲突」。如果想要不丢失用户数据，这种修改冲突只能依靠用户手动去解决，任何自动化的方式均可能弄错或弄乱。但即使提示了用户冲突，用户又该如何解决呢？这同样是一个问题。

目前思源的方法是将同步功能化简为「云端覆盖本地」和「本地覆盖云端」两种情况，算是用一种固定的方式解决了修改冲突。这种方式杀伤力巨大，所以要用户手动触发。可以想象一下，如果是自动触发，同时修改文件将直接导致丢失当前修改这种事情发生。

真的很需要自动同步，有两种方式可以考虑：一种方式是将「工作空间」内的「data」目录使用网盘同步，用网盘去解决冲突（没有冲突就皆大欢喜），这样放弃思源备份的端到端加密安全性，换来方便性；还有一种是将「data」目录自建为 Git 仓库，使用 Git 的同步机制，冲突解决起来容易一些。Git 同步的方式不适合一般用户，要折腾可以自己搞。

已明确是「使用现有数据库」造成的，手工在 conf.json 中停用该选项，重新启动就正常了。

刚才杀死了思源的内核进程，重新启动后卡在另一个文件（日记已经被删除了）。上面的日志里面有错误信息。

日志里面好像有问题发生：

I 2021/06/07 20:17:18 working.go:364: port [6806] is opened, try to check version of running kernel
I 2021/06/07 20:17:18 working.go:374: version of the running kernel is [1.2.0-beta3]
I 2021/06/07 20:22:02 working.go:364: port [6806] is opened, try to check version of running kernel
I 2021/06/07 20:22:02 working.go:374: version of the running kernel is [1.2.0-beta3]
I 2021/06/07 20:22:42 working.go:99: 
  ____    _  __   __
 / ___|  (_) \ \ / /  _   _    __ _   _ __
 \___ \  | |  \ V /  | | | |  / _` | | '_ \
  ___) | | |   | |   | |_| | | (_| | | | | |
 |____/  |_|   |_|    \__,_|  \__,_| |_| |_|

I 2021/06/07 20:22:42 working.go:100: kernel is booting:
    * ver [1.2.0-beta3]
    * runtime mode [prod]
    * workspace directory [/Users/zyang/Share/Library/SiYuan]
    * working directory [/Applications/SiYuan.app/Contents/Resources]
    * temp directory [/var/folders/tl/fpjx4p3949lgt9hptw4x9f800000gn/T/siyuan]
    * system temp directory [/var/folders/tl/fpjx4p3949lgt9hptw4x9f800000gn/T/siyuan]
    * rsync directory [/Applications/SiYuan.app/Contents/Resources/rsync]
    * read only [false]
    * container [std]
    * resident [true]
    * arch [amd64]
I 2021/06/07 20:22:42 conf.go:209: local serve path [http://192.168.1.2:6806]
I 2021/06/07 20:22:42 serve.go:50: kernel HTTP server is booting [http://0.0.0.0:6806]
I 2021/06/07 20:22:44 box.go:522: rebuilding database of box [我的笔记]
E 2021/06/07 20:22:44 database.go:858: exec database stmt [DELETE FROM attributes WHERE box = ?] failed: no such table: attributes
E 2021/06/07 20:22:44 database.go:858: exec database stmt [DELETE FROM refs WHERE box = ?] failed: sql: transaction has already been committed or rolled back
E 2021/06/07 20:22:44 database.go:860: rollback database transaction failed: sql: transaction has already been committed or rolled back
E 2021/06/07 20:22:44 upsert.go:72: insert tree [url=http://127.0.0.1:6806/siyuan/1614700942141/我的笔记/, path=/A-技术研发/技术探索/数据抽取工具.sy] into database failed: no such table: attributes

居然在 Log 里面看到 V 姐的名字，BUG 有主了。:D

看起来是内部有什么东西崩溃了。我也尝试了全新重启（不重用数据库），结果没有变化。

I 2021/06/06 10:04:36 working.go:99: 
  ____    _  __   __
 / ___|  (_) \ \ / /  _   _    __ _   _ __
 \___ \  | |  \ V /  | | | |  / _` | | '_ \
  ___) | | |   | |   | |_| | | (_| | | | | |
 |____/  |_|   |_|    \__,_|  \__,_| |_| |_|

I 2021/06/06 10:04:36 working.go:100: kernel is booting:
    * ver [1.2.0-beta2]
    * runtime mode [prod]
    * workspace directory [/Users/zyang/Share/Library/SiYuan]
    * working directory [/Applications/SiYuan.app/Contents/Resources]
    * temp directory [/var/folders/tl/fpjx4p3949lgt9hptw4x9f800000gn/T/siyuan]
    * system temp directory [/var/folders/tl/fpjx4p3949lgt9hptw4x9f800000gn/T/siyuan]
    * rsync directory [/Applications/SiYuan.app/Contents/Resources/rsync]
    * read only [false]
    * container [std]
    * resident [true]
    * arch [amd64]
I 2021/06/06 10:04:36 conf.go:199: local serve path [http://192.168.3.108:6806]
I 2021/06/06 10:04:36 serve.go:50: kernel HTTP server is booting [http://0.0.0.0:6806]
I 2021/06/06 10:04:38 box.go:517: use existing database of box [我的笔记]
I 2021/06/06 10:04:42 working.go:125: kernel booted
E 2021/06/06 10:04:50 log.go:48: PANIC RECOVERED: runtime error: slice bounds out of range [:-1]
	/usr/local/go/src/runtime/panic.go:965 (0x403c158)
/usr/local/go/src/runtime/panic.go:98 (0x4039aa4)
/Users/Vanessa/Work/Code/siyuan-src/kernel/model/assets.go:237 (0x4aee429)
/Users/Vanessa/Work/Code/siyuan-src/kernel/cmd/unusedassets.go:17 (0x4ba95d8)
/Users/Vanessa/Work/Code/siyuan-src/kernel/cmd/cmd.go:209 (0x4ba9792)
/usr/local/go/src/runtime/asm_amd64.s:1371 (0x4076ce0)

I 2021/06/06 10:04:58 conf.go:237: exited kernel

文本文件在版本管理、增量同步等方面优势非常明显。目前的 JSON 格式扩展起来也很容易。目前的内存中用数据库，磁盘上用文件，数据库会写磁盘加速启动的方案同时兼顾了数据库的效率和文件的灵活性，我觉得是一个相当深思熟虑的考虑。

已发送邮件。

这样客户端虽然麻烦一点，但能启用高级功能，也是值得的。两重加密验证也保证了激活文件无法被二次分发。

我也有类似的需求。

一点不成熟的想法，共探讨：思源笔记根据客户端的网卡 ID、当前日期等信息生成一个激活字符串和客户端 RSA 密钥对，将激活字符串和 RSA 公钥组合为一个数据文件；客户将这个数据文件发送给思源官方，思源官方根据激活字符串生成一个验证码，用客户端公钥加密并用官方私钥签名，形成激活文件。客户下载激活文件，导入客户端，客户端用官方公钥验证签名并使用客户端私钥解密后，确认激活信息匹配客户端身份。如果匹配，则生成一个有限期限的 Session Token，实现离线登录。

等有人力富裕开发 IOS 版本也很有意义。JOPLIN 都有 IOS 版本，全平台在笔记软件里面是一个优势。