开发者工具版本：1.05.2102010 情况 如果选择2.14.3以上版本的基础库，开启云函数本地调试没有反应 -------------------- 没有用的故事 折腾了很久，下了10个开发者工具版本，各种调试花了1天，才发现这个问题。脑袋很疼

开发者工具版本：1.05.2102010 （试过10个版本也是不行） 表现： 云函数同步成功云函数开启本地调试成功但是无论这么测试都没有任何调试结果，说明并没有触发到本地调试 之前有成功过，但是没有任何不一样的地方，所以找不到来原因 另外就算把开发者工具关了，还是有很多node进程没有被退出 有没有什么临时的办法可以保证一定能运行就算操作麻烦一点 [图片]

export class Query { constructor(name: string) public readonly collectionName: string where(condition: IQueryCondition): Query orderBy(fieldPath: string, order: string): Query limit(max: number): Query skip(offset: number): Query field(object: object): Query get(options?: IGetDocumentOptions): Promise<IQueryResult> | void | string update(options?: IUpdateDocumentOptions): Promise<IUpdateResult> | void remove(options?: IRemoveDocumentOptions): Promise<IRemoveResult> | void count(options?: ICountDocumentOptions): Promise<ICountResult> | void | string } 这里的返回值能否使用泛型类似于 get<T>(options?: IGetDocumentOptions): Promise<T> 或者使用重载 get(options?: IGetDocumentOptions): Promise<IQueryResult> get(options?: IGetDocumentOptions): void get(options?: IGetDocumentOptions): string 因为现在使用Typescript的过程中无法通过检查

背景是今天为了配置云开发环境，更新了开发者工具，然后发现了「可视化」这个功能。 当看到这个功能的时候，脑子里冒出了好多想法。 想法一：为什么搞这个功能？ 首先，看到「可视化」这个功能，第一个想法是『搞这个干嘛？』，可视化代码发展了几十年了，除了AI to Code这个方向还是有点意思以外，其他的可视化工具真的近乎『毫无用处』，这一点大家也讨论很多了，不讨论了 重点是『为什么搞了这个？』，因为能看得出现在这个功能就是团队某个程序员的想法而并不是一个战略方向。 而明明微信小程序开发还有填不完的坑，更重要的事情去做，为什么搞了这个？ 我的想法是希望开发团队的资源应该还是在填坑上，不求创新（最好也不要，太恐怖了）但至少多填点坑。 想法二：希望能看到微信小程序的开发计划 第二个想法就是希望能看到微信小程序的开发计划，因为现在开发者离微信小程序开发团队距离还是很远。（目前社区并不解决这个问题，虽然实际上明明可以） 距离远就会导致很多误解，这是很正常的情况，因为信息不对等不开放，所以每个人只能站在自己的角度和自己所掌握的信息进行判断。 这就造成对于微信开发者团队来说，『明明已经做了很多了，但是为什么开发者还是不满意？』。而对于开发者团队来说就是『开发者团队到底再做什么，是不是都没在做事』或者『能不能做点更重要的事』。这也是我第一个想法产生的原因 缩短距离的方法有很多，例如 开发者社区开发计划...等一下，看到这里肯定会有疑问，因为提到的方法微信小程序开发者团队不是做了吗？ 问题就在这！现在做得效果 = 没有。为什么没有用？（关于这点，之前也讨论很多了） 首先，我总是觉得微信开发者团队的频道和正常用户不太一样，即很多做法会让人觉得更莫名其妙 其次，到现在还是搞不懂微信开发者团队是不是想缩短于开发者的距离 回到方法上 首先，一个开发者社区应该是类似于一个和官方沟通的渠道。但目前更像是一个工单中心，所以只能说这并不是一个社区的概念。那是不是等于没有 其次，开发计划 微信开发团队其实每周都有公布开发计划，但目前来看更新像是一个（反向）更新日志。也是等于没有。用户想要的仅仅只是一个类似看板一样的页面，能够通过时间、便签等筛选的纬度去找到自己想要的信息 所以问题在于如果确实想要做社区和开发计划为什么最后做的是反向的东西？当然会有人说『每个人想得不一样』『我觉得已经做得很好』『有总比没有好』一些想法。但希望能互相理解一下，这是我站在产品设计角度和个人思考的看法，所以希望不要看到一些『不理性』的回复 说了这么多，那到底『我想要什么呢？』 一、希望有人认认真真维护一下开发者文档 不开玩笑的说，开发微信小程序，30%的时间在找和理解文档，30%的时间在填因为文档写错了或者没写的坑，20%的时候自己再封装一次功能。10%再思考为什么要怎么搞。最后才是10%的时间编写代码 所以希望能有人可以维护一下开发者文档。帮大家减少至少50%的开发时间。当然更好的情况是能够让至少有点『用户体验』的人去维护，这样可以再减少30%的开发者时间 就是这件事情真的很严重，就算再小的团队都要解决的问题，所需要的人员可能要求仅仅只是个实习生都行 而且这件事只能官方来做，因为没有人有那么多时间/经验/义务去维护一个第三方文档。 二、希望有真开发计划看板 目前微信小程序团队很多做法让人很奇怪的是，到底是给谁看？例如很多开发上的事情除了程序员谁看啊？ 而针对程序员来说，开发计划非常的重要，而微信小程序明明是可以这么做也必要这么做。 一个简简单单的看板真的就能解决这样的问题，付出的资源可能也是一个实习生就行。 但解决的问题确实很重要的，至少能解决开发者很多时候搜索的时间以及对于提升好感 三、希望能有社区产品经理 就目前行业来说，国内的程序员还是不需要「用户体验」「战略」或者其他能力的基础要求。那么更适合还是面向程序这端，而社区产品还是需要面向用户的，那么简简单单能有一个有一点点技术背景的产品经理还是不错的 当然衍生的话，很多国内程序员会有错觉觉得自己有这样的能力，但实际上真的『大可不必』。因为产品和程序员的工作隔阂真的太大了，思考的方向和内容差太远。当然这是另外的一个话题不讨论。 四、认认真真做一下开发者工具 在几年前我还在用MacBook Pro 16年版本的时候，我觉得如果我开发h5，可以再战个10年。但是于到小程序开发者工具直接把我的电脑屏幕烧了，还好还在保修 去年为了运行微信开发者工具换了MacBook pro 16存，结果还是卡爆了。什么也不做已经感觉很卡，开发起来的时候直接烫手 今年在家配置1w块的电脑为了开发（打游戏），我以为GTA特效全满对付开发者工具应该没问题，结果我错了，编译速度是快了，但是多编译几次还是卡起来了。 当然这并不是微信开发团队的问题，electron本身就会很卡。但是自己也开发过也不太可能卡成这样。 所以，我希望 认认真真开发重写一些开发者工具只有编译的开发者工具，不要有什么编辑器之类的，对于一般程序员真的完全用不到还卡

很久没看云开发，刚刚看到有云托管的方案。这个方案很好或者说本来就应该这个方案，简单点就是真正的serverless云函数 当然对于开发者来说最好的一点就是终于不用限制开发语言了，放开了这点好处太多了 然后现在我最大的想法就是缺少本地的开发调试，目前来说开发流程是 本地盲写代码进入小程序云开发进入云托管上传文件夹代码（本来想用git仓库，结果绑定后一直报「出现一些问题」所以不能用）经过超长时间的持续构建然后返回小程序调用发现没写好重复上面流程 这就产生一些问题 第一个问题：真的是这样的开发姿势吗？ 这种开发效率也太低了吧 目前来说，理想中有两种方案 第一种是和serverless一样支持本地开发环境，即有本地开发环境，不需要先上传到线上 当然最理想的情况肯定是和midways的hooks一样的，本地调用云函数跟普通函数一样的方法，好处比较多。 第二种是用工程化来解决，但这不如第一种的好。 我知道这个以后肯定会支持，所以有下面第二问题 第二个问题：现在推出云托管的目的是什么？ 是第一个问题的衍生，即现在开发这玩意这么麻烦，有跟没有一样。 我的想法也就是说应该先去解决如何更简单更高效的开发，而不是先上这个功能。 原因有很多，例如已经有了云函数了，这个云托管并不急这种。但云开发的产品经理有自己的考量，我只是提出我的想法 第三个问题：推出云托管的意义是什么？ 或者说 对于原云函数的意义是什么？是否会替换原云函数？有了原云函数，为什么会推出云托管？ 很早之前尝鲜过小程序的云函数，总体来说就是疑问是『为什么不直接使用市面上的云函数方案而是「定制」了一下？』，导致开发的时候比真云函数来说效率变低，限制变多。 然后我的想法是既然有了云托管（真云函数），那原有微信小程序版的云函数应该就没有必要了 因为云托管解决了原原函数的很多开发问题和扩展性问题 ，是绝对替代方案 或者说原函数方向错了，最后还是回归到正道上。毕竟从解决需求和技术设计实现上都是相同的 并且对于普通微信小程序开发者来说，理论上如果完善一下现在的云托管，可以说完全没有区别（用户角度）。 相关问题：《使用云托管，本地和线上环境不一致的问题？》

背景 我使用wx.getLocation api, 然后提示我要在app.json里声明permission，然后我打开了app.json，但是我发现我不知道要这么配置然后我打开了文档，搜索了wx.getLocation的api文档，发现并没有说到这个情况。（https://developers.weixin.qq.com/miniprogram/dev/api/location/wx.getLocation.html），只说要授权然后我到了授权，我发现没有说到permission的情况这个问题， wx.getLocation的文档没有告诉开发者要在app.json中声明，导致开发者试了以后才说有这个问题，浪费了一些时间然后 我想在文档中搜索「permission」看能不能找到如何配置，结果发现找不到正常逻辑的链路完全断了 最后 从头看文档，找到框架，小程序配置，全局配置最终才找到内容 需求 为了可以节省各自的时间，希望能完善一下这部分文档的内容 wx.getLocationApi中告诉开发者要先声明权限，及响应文档地址在搜索中，能够直接搜索到'permission'的相关内容

疑问一：现在获取到的结构为什么多了一些内容 理论上的结果 interface SubscriptionsSetting { itemSettings: Record, mainSwitch: boolean } 但是现在实际返回的是 interface SubscriptionsSetting { [tempId: string]:string, itemSettings: Record, mainSwitch: boolean } 这个[tempId]和itemSettings里是一样的 为什么外面也有这个？有没有什么情况下有[tempId]没有itemSetting？会不会有什么其他影响，比较担心这个，怕有什么坑，不然为什么不去掉 疑问二：itemSettings为什么是在点击过总被允许才出现？ 在https://developers.weixin.qq.com/miniprogram/dev/api/open-api/setting/wx.getSetting.html中才有说到「withSubscriptions 只返回用户勾选过订阅面板中的“总是保持以上选择，不再询问”的订阅消息。」 这个文档位置逻辑有点问题，理论上应该在https://developers.weixin.qq.com/miniprogram/dev/api/open-api/setting/SubscriptionsSetting.html这个文档也该出现

[图片]试了一下才发现不支持，那为什么还在列表上

背景 接入开发模式后，我想要和管理后台一样看到消息管理的记录可以和管理后台一样查看到所有最近记录，而不是接入开发这模式以后的记录 因为现在接入开发者模式后，发现如果要看以前的记录还得登录后台查看，这个非常不可行 如果是利用接收普通消息接口，服务器接收然后在保存在后台服务上，那就会涉及更多的问题 如果后台服务不可用会导致记录丢失且无法同步后台服务需要记录和维护大量的聊天数据，感觉没有必要如果利用多客服接口，明显有点杀鸡焉用牛刀 需求 提供消息列表接口，可以主动获取近5天的聊天记录

个人不能申请可以理解，测试号都只有自己用了 为了避免每个人理解能力不同，我把问题再说直接一点 我认为 测试小程序应该具有完整的测试权限（文档里自己也是这么写的），所以我想要用测试号去体验URL Scheme的功能