很久没看云开发，刚刚看到有云托管的方案。这个方案很好或者说本来就应该这个方案，简单点就是真正的serverless云函数

当然对于开发者来说最好的一点就是终于不用限制开发语言了，放开了这点好处太多了

然后现在我最大的想法就是缺少本地的开发调试，目前来说开发流程是

• 本地盲写代码
• 进入小程序云开发
• 进入云托管
• 上传文件夹代码（本来想用git仓库，结果绑定后一直报「出现一些问题」所以不能用）
• 经过超长时间的持续构建
• 然后返回小程序调用
• 发现没写好
• 重复上面流程

这就产生一些问题

第一个问题：真的是这样的开发姿势吗？

这种开发效率也太低了吧

目前来说，理想中有两种方案

第一种是和serverless一样支持本地开发环境，即有本地开发环境，不需要先上传到线上

当然最理想的情况肯定是和midways的hooks一样的，本地调用云函数跟普通函数一样的方法，好处比较多。

第二种是用工程化来解决，但这不如第一种的好。

我知道这个以后肯定会支持，所以有下面第二问题

第二个问题：现在推出云托管的目的是什么？

是第一个问题的衍生，即现在开发这玩意这么麻烦，有跟没有一样。

我的想法也就是说应该先去解决如何更简单更高效的开发，而不是先上这个功能。

原因有很多，例如已经有了云函数了，这个云托管并不急这种。但云开发的产品经理有自己的考量，我只是提出我的想法

第三个问题：推出云托管的意义是什么？

或者说

• 对于原云函数的意义是什么？
• 是否会替换原云函数？
• 有了原云函数，为什么会推出云托管？

很早之前尝鲜过小程序的云函数，总体来说就是疑问是『为什么不直接使用市面上的云函数方案而是「定制」了一下？』，导致开发的时候比真云函数来说效率变低，限制变多。

然后我的想法是既然有了云托管（真云函数），那原有微信小程序版的云函数应该就没有必要了

因为云托管解决了原原函数的很多开发问题和扩展性问题 ，是绝对替代方案

或者说原函数方向错了，最后还是回归到正道上。毕竟从解决需求和技术设计实现上都是相同的

并且对于普通微信小程序开发者来说，理论上如果完善一下现在的云托管，可以说完全没有区别（用户角度）。

相关问题：《使用云托管，本地和线上环境不一致的问题？》