2）在空间信息流中，如果你给朋友的某个动态发表评论，但写了一句，没发布；继续看空间下面别的信息，过一会，回头如果再点开刚刚那个说说的那一条动态给评论；你就会发现刚刚编辑的那句话竟然还在，可以接着编辑。
3. 云端存储
说起云端存储就有人会问怎么判断：某个产品的某些功能中保存类似草稿内容是存在用户端本地呢，还是上传到平台服务器端了呢？
这里有一个小方法：换一个终端设备登录，看看还能不能看到之前编辑的草稿内容。
如果能看到，则保存的未完成的内容是备份到服务器端的，如果看不到之前的草稿内容，则是保存在用户终端的。
根据这个小方法测试发现：印象笔记，在用户编辑内容的时候，会程序化自动周期性备份内容到服务器端。QQ的草稿箱，一个是发布说说草稿，一个是评价好友动态草稿，均保为本地存储，换了设备登录是看不到之前编辑的草稿内容。
1.3.1 草稿应不应该上传云端呢
1）必要程度
弄明白为什么需要用户草稿箱的具体内容，如果不上传具体草稿箱内容是不是可以；如果上传到平台上来，下一步能干什么，这些数据是不是对产品或运营策略有实际的用途。
比如我们都很熟悉的电商平台的购物车功能，这就是我们购买产品的草稿箱。而且这些数据也确实上传到了平台，平台通过技术手段，结合用户购物车数据，实现个性化营销。千人千面，进一步完成销售的目的，那么这是必要的。
再看，像抖音内容草稿箱、微信发布朋友圈草稿等；就算把草稿内容上传到平台，但对产品运营没有实际支撑用途，也是没有必要的。
2）隐私程度
虽然说互联网的世界里面没有隐私，但能做的还是得做。至少平台本身得去帮助用户，解决一些不必要的隐私泄露问题。
从隐私的维度看，越是隐私的未发布的内容，就要尽量让数据保留在用户自己手里。
平台可以通过技术获取用户草稿箱的统计数据，或者特征数据。宏观层面的，比如不同用户一般有多少条草稿内容。但，确实是没必要去获取用户草稿具体内容的，原因很简单，用户没公开发布。
要知道在社交平台用户注重隐私，多一个存储位置备份，就多一份风险。
二、自动保存1. 延迟草稿存储
目前市面上大部分产品都具备延迟存储功能，例如：Word、Axure、Xmind、ZBrush、CAD、PohtoShop等等；特点：
- 在工作暂停间隙间自动保存；
- 如果没有连续工作没有暂停，则每隔X分钟自动保存一次（时间可由用户设置）；
- 在后台默默地保存，没有提示和进度条，不会干扰用户；
目前在这方面MAC做的比较全面
2. 随机草稿存储
特点：
- 每隔几秒自动保存一次；
- 可以看到上次自动保存的时间，并且可以手动保存；
- 所有自动保存的版本都留着，可以随时回退到其中的任何一个版本；
- 在WordPress.com上撰写和编辑帖子和页面时，所做的更改每隔几秒钟会自动保存一次。在在编辑器右上方的发布模块，你会看到从通知举动保存草稿到自动保存到已保存。
以简书为例：简书中的编辑器即草稿箱，每次修改都会随时保存，“发布文章”按钮自动变成“保存中…”以提示正在保存。
点击“发布文章”按钮，文章发布，按钮变成“已发布”。
对于“已发布”的文章，再次编辑时，依然会出现“保存中…”字样提示正在保存。已发布的文章自动保存后，按钮变成如下的“发布更新”，再次点击后才会变成“已发布”。
3. 条件草稿存储
特点：
- 每隔一段时间或者一个触发条件自动保存一次；
- 当用户手动关闭文档之后，自动保存的版本会被清空（部分可选择是否保存历史记录）；
- 如果是非正常关闭，如电脑死机或者断电，异常自动保存的版本会保存在硬盘上；
- 当你打开文件时，如果检测到一个异常自动保存的文件，它会提示你保存或者打开该文件；
条件存储顾名思义就是由某个条件触发从而达到保存的目的，比如PohtoShop中的历史记录功能，就是根据用户使用工具后到使用下一个工具前作为触发条件进行存储记录。不过因为步骤较为繁琐这些操作存储都为本地存储，并未上传云端。
Microsoft：对表单所做的任何更改将在更改后30秒自动保存。
如果未对表单进行任何更改，则在打开表单时不会自动保存。进行更改后的30秒内，将再次开始自动保存。某人当前正在编辑的字段不包括在自动保存中。如果其他人在编辑时更新了同一条记录，那么当自动保存时，这些更改将被检索并显示在表单中。
以简书为例：简书编辑是在0.5S左右会自动保存一次，通过抓包可以看到在编辑的时候如图所示：
可以得知每次编辑之后简书都会向服务器对应的url发送数据；需要注意的是发送的方式为put而不是post。
因此不难得出，在实现类似自动保存功能的时候，需要向服务器put方式发送数据，并且在检测到鼠标没有输入之后的0.5S左右自动想服务器put一次数据。
简单地说：通常用于向服务器发送请求。
- 如果URI不存在，则要求服务器根据请求创建资源，如果存在，服务器就接受请求内容，并修改URI资源的原始版本。——PUT请求那些封装在Request-URI的实体。
- 如果Request-URI引用一个已存在的资源，则该封装实体应该作为原始服务器上的修改版本。
- 如果Request-URI不是指向一个已存在的资源，并且该URI可被请求的用户代码定义为新资源，则原始服务器可用此URI创建新的资源。
- 如果新的资源被创建，这个原始服务器就必须通过201（Created）响应通知用户代理。
- 如果已有资源被修改，则发送200或者204响应，表示成功完成了该请求。
- 如果Request-URI既没有创建也没有修改资源，则应给予适当的错误响应来反映问题本质。实体的接受者不能忽略任何不理解或没有实现的Content-*（如Content-Range）头部，并且必须返回501响应。
- 如果请求经过缓存，并且Request-URI标识出一个或多个当前缓存的实体，则那些实体视为过期了，该方法的响应不会被缓存。POST请求的URI表示处理该封闭实体的资源，该资源可能是个数据接收过程、某种协议的网关、或者接收注解的独立实体。然而，PUT请求中的URI表示请求中封闭的实体-用户代理知道URI的目标，并且服务器无法将请求应用到其他资源。
- 如果服务器希望该请求应用到另一个URI，就必须发送一个301响应；用户代理可通过自己的判断来决定是否转发该请求。
