试了下去掉边框，个人感觉更好一点。不过我还是投了反对票，因为不想改的人挺多的，而对于想改的人来说，这类简单的需求可以直接 CSS 就实现了。

如果真的改 UI，可以考虑出份设计稿大改一下。不过，相对于这些细枝末节的元素，我倒是觉得不如花心思优化一下界面的逻辑，精简和合并一下入口之类的，目前还是有点乱（比如我始终理解不了文档右上角的“打开菜单”和“更多”是靠什么区分的，为什么导入导出功能不在“更多”里面）。

上面讨论的边框的问题，感兴趣的可以用这个 CSS 看下效果：

/* 隐藏界面边框 */
.layout-tab-bar {
	border-bottom: none;
}
.layout__resize--lr:after {
	top: 0;
	width: 0;
	left: 0;
	height: 0;
}
.toolbar {
 	border-bottom: none;
}
.dock#dockLeft {
	border-right: none;
}
.dock#dockRight {
	border-left: none;
}
.status {
	border-top: none;
}

最爱 Bear 的设计，真正的简洁好用，交互做得非常好。Notion 移动端就别学了吧，重新设计之后依然是一坨。

另外一个做得不错的是 Craft。

我没有使用思源的数据库，我个人更在意的是移动端的体验优化 😂 。功能再精简一些我都觉得 ok。

我之前也总是失败，后来把时间改成 180s 好像就全部 ok 了。默认的好像是 30s 吧。

我个人还是喜欢传统的三栏式

在数据历史里面找之前的快照恢复。只要没有刻意删除过，数据一般是不会丢的。

应该是因为云端那份数据已经出问题了吧，所以覆盖本地永远会是 untitled。至于最初怎么出问题的，我没法确定，但确实之前也遇到过。回帖里面也有朋友有类似的经历。

按你说的办法做了，还是会覆盖本地。

systemlog1.zip

谢谢，我先试试能不能覆盖，不行就只能清空存储桶了。（用的 R2，清空好麻烦）

对的。我看数据快照里面已经有新的快照。

不太懂思源的同步逻辑之类的。

现在只想把本地的完整覆盖云端。

但是点同步又会把之前的一堆 untitled 下载下来，我通过快照恢复的这个版本能不能直接完整覆盖云端的那个版本呢？

我已经通过昨天早上的数据快照恢复了数据，如何将本地数据覆盖云端呢？直接点同步会把之前的数据下载下来。

补充一些信息：

我想了一下很有可能是昨天下午我在另外一台 Mac 上全量下载我的笔记之后出现问题的。我刚刚断网检查了一下数据，iPhone 是正常的（因为这两天没打开过），另外那台 Mac 数据是错的。

这是我另外一台 Mac 断网导出的日志文件，我很确定当时是等待程序同步完成之后正常退出的。

systemlog2.zip

同样很难理解 😂 ，现在只要不出感叹号我都不看这几个数字了。其实大多数用户只关注有没有同步成功。

确实极其难用，从 UI 到交互完全不是移动端 App 的逻辑。

就说几个最影响体验的：

1. 打开和关闭慢。切到后台再切回来总是有数据校验的提示框。
2. 强制全量下载，资源类附件无法懒加载，如果附件多，移动端会占用大量空间。
3. 点击事件没有对移动端优化。比如图片需要点两三下才能放大，因为要先点击选中，完全不符合移动端使用习惯。

前 2 点，应该是同步方案的限制，目前的云端更像是一个备份中心，用来在需要的时候从云上下载一份笔记而已。第 3 点以及没有提到的很多反直觉的交互问题，可能就是开发者确实不太关心移动端的体验优化或者说解决起来很麻烦优先级太低。

大兄弟，一个笔记软件里面加签到你是要干嘛？

“提高软件使用信心”，神了 😂。

我这两天仍然频繁遇到，不知道什么情况会触发这个问题，每次刷新一下才会重新出来。

重启之后确实重新出现了，感谢！

我个人就完全没有用到各种链接。

最看重的几个核心要素是：本地存储 + 可靠的云备份 + 传统文档树结构 + 富文本编辑器。

本地存储是最重要的，因为可以保证图片类资源文件秒加载，这也是我没有用 notion 的主要原因。

我个人是隐藏了页面上很多元素，应该是这段代码可以做到

/* 隐藏页面滑块 */
.protyle-scroll {
  display: none;
}

文档树加竖线真的好丑... 如果要加希望能给个开关

感谢，我还真没注意过有超时这个设置，刚刚才看到，改了后续观察一下。

个人笔记里面大量使用图片，昨天晚上 S3 同步到一台新设备，中间一直失败，大概失败了十几次才同步完......而且 S3 同步是真的慢

以前用 kindle，后面买过文石，不过都吃灰了，现在只用 iPad 了，体验好的不是一点半点。护眼主要还是用眼习惯吧，长时间看纸书也伤眼的

ok 感谢

白板想要做的好可太难了。最重要的可能是交互逻辑和性能问题。

简单的使用场景随便什么白板都能用。稍微复杂一些的使用场景，目前各个笔记里面集成的白板基本都是一坨。

要做的话，先把大多数有白板需求的用户使用场景搞清楚吧，可以做做调研什么的。

不过个人意见暂时是没必要做这个功能，开发资源毕竟有限，而现阶段需要优化的地方可太多了。

复议。个人使用场景里面，父文档当目录的情况远远多于有内容的情况

好吧 ～

是的吧，郁闷。不知道问题怎么出现的，所以也就不知道下次如何避免。

现在希望这个问题能被修复，还有怎么方便清除之前这些问题图片上的多余属性，笔记中的图片实在有点多，一个个打开开发者工具删除太麻烦了。

找了个图片试了一下，拖动调整宽度似乎只会添加一个 width 属性，那这个 max-width 是怎么出现的？