@puga2006 在苏州，是的，iOS 也可以帮忙内推。

@yizhimamong 对此没有要求
@xw900812 本人在微软开发 Android，所以是内推。之所以没使用 Microsoft 邮箱，是因为 Microsoft 邮箱不是 drakeet alias，相比之下我就更喜欢自己的域名邮箱。

@a704320567 已支持

龟苓膏

@isundust 是的，很多大厂提供的云同步都错误百出...

@shimomiaizo 感谢，大后期有可能。

@xiaoyuanmio 云同步准备和计划中，不过得等 3.x 版本对细节友好和调整达到更完美的程度时，才好再次空出大量时间专注做好云同步。

@extra888 分身乏术，目前没有计划支持 iOS

@zuolan 纯纯写作拥有多重防备：1. 保存失败时立马提醒告知用户； 2. 自动保存历史记录； 3. 自动备份整个数据库。

之所以至今都没有支持云同步的原因是，云同步在我看来比较 evil，当初我之所以开发纯纯写作，也是因为经历了许多带有所谓「云同步」的便签应用然后经常因为它们的同步导致我的文章大量丢失或错落，因此可以说，国内做此类云同步服务的大多存在很多问题，云同步能带来便利，但却十分危险。关于同步和协作，我们写代码天天在使用的最强大的 git 版本控制都免不了经常要人工介入进行合并冲突。而国内大多云同步服务都全程自动化，版本号不可见，于是发生冲突、丢失、失败都很常见。
另外，如果你去酷安查看一些拥有云同步功能的编辑器应用，会发现它们底下的用户评论很容易找到各种用户抱怨云同步导致丢失、带来错误。

最后来说，实际上我仍然是反对云同步的，但确实很多很多用户请求加入这个功能，因此我也不能不考虑用户呼声，纯纯写作从第一天开始，我就对自己说，这是要听从用户的，所以一直以来才非常积极友好地与用户交流、接受反馈。至于云同步，在 3.x 阶段将会实现，或许会砍掉许多危险的行为，追求便利和可靠的平衡吧。

@Willjim 嗯，感谢建议！
由于我不喜欢限制用户，因此高级版内容都偏向无关紧要内容，而且至今也只有两个小功能（预览和自定义信纸），下次会加上说明。
自动备份放在 data 下不友好，而且会被随着软件卸载而自动清空。

@Willjim 太好了，感谢你的推荐和建议。

@a570295535 因为我为了避免文章看起来很长，刻意没有插入很多截图，还是留给用户自行探索好了

很棒，但需要确认一下...

纯纯写作，Google Play 平均近 4.8 分

SQLite，不需要并发，文件内容包含历史记录文件，单个文件长度应该极少上十万字的，都是纯文本，但可能会很多，越来越多。

@loading 谢谢，我这边是客户端需求，使用 SQLite，因此不存在 nginx _(:з」∠)_

我想的是，如果性能差别不大的话，那么绝对是完全数据库存储会方便很多，这是可以接受性能损失的。因为我不需要一次性读取或操作大量文件。

@saulshao 这样有考虑过，怕断层，比如数据库被删了，但文件没被删，就变成垃圾文件了——不过这个问题不大，在私有目录下，这种情况应该极少发生。

@xvppdd 你可能没见过大项目。