小编表示，腾讯在移动互联网时代的核心产品，庞大的用户量，以及无数媒体的分析和追捧，让微信不断成长与赞美。
微信真的完美吗？让我们听听来自 PM 的不同声音。
（这位PM很害羞，所以保持匿名，但欢迎你在文章下跟他评论，他会匿名回复你。
） 注：该图不针对任何账号或人，仅供参考与文章内容相符，敬请理解：）这是对微信的吐槽，并非认真分析。
如果你和我一样被微信的某些缺陷所困扰，欢迎在评论区与我讨论。
我觉得朋友圈是一个很好的功能：我会关心朋友的近况。
毕竟聊天时并不是所有事情都会讨论。
您只能看到好友在朋友圈中的内容。
结果，在朋友的动态更新中，经常会看到A说“好吧，我们总结一下大家的问题，一一解答”。
问题是大家的疑问是什么？你为什么看起来这么困惑？原来，我没有关注A的其他好友B、C、D……，所以看不到B、C、D……的回复，所以整个状态更新环节都是莫名其妙的回复。
我觉得Twitter的@机制很好。
如果我的朋友@了另一个我不关注的人，那么这条消息将不会出现在我的时间线中，并且不会出现没有上下文的对话问题。
。
对应上面的文章，因为我在朋友圈里看不到任何不认识的人的信息，所以我不可能通过朋友圈扩大我的朋友圈（这个问题可以在群聊中部分解决）。
解决了，不过朋友圈和群聊可能不对应同一群人。
） 总的来说，我个人更喜欢Path的逻辑：以朋友圈为主体，聊天为补充，就能找到通过朋友更新的回复。
一些有趣的新潜在朋友。
公众号然后发生了一件非常奇怪的事情。
原本用来和熟人社交的微信账号，突然多了一个和熟人无关的公众号。
我想看自媒体，博客、微博就不能看吗？为什么要在微信上阅读？好吧，我其实知道为什么。
因为“博客太分散，维护成本太高，沟通能力不够”，因为“微博没落，僵尸账号发垃圾”，“你看我的微信朋友圈有多少人点赞，有有多少朋友转发了此信息？“一方面，我不在乎有多少人“喜欢”我的东西，如果你真的认为你喜欢它，就发一条有价值的回复即可；另一方面，朋友圈里的个人状态更新对我来说是有好处的。
因为其他人可能对这个信息不感兴趣，但是公众号啊，你要关注它才可以浏览。
RSS 订阅的变体，但分享它，或者只有朋友可以看到它，它根本不是“公开”的，如果我想在其他地方分享它，我必须“复制链接 - 打开浏览器 - 与浏览器分享”。
现在是移动互联网时代吗？感觉就像是前互联网时代……相比之下，微博的公众会员更多，而公众号则无法面向公众的读者发布内容。
账户之间可以互相交流，而在博客和微博上，我可以很容易地看到其他读者并参与讨论（虽然可以分享到朋友圈进行讨论，但这也是上面提到的问题。
。
朋友圈里的朋友并不是本来可以公开讨论的同一群人）。
虽然公众号常用的“微社区”可以将读者聚集在一起，但他们在“微社区”中谈论的事情实际上可能与公众号发布的内容没有太大关系，内容和交流也有很大的不同。
被剥夺了。
。
必须承认，微信公众号的维护成本确实比独立博客低，而且很容易获取关注者数据，这对于自媒体来说是有帮助的。
然而，推广公众号并不是那么简单。
一方面。
，因为朋友圈分享的内容只有好友可见，所以传播力和可发现性都会受到影响；另一方面，如果想要在微信以外的渠道进行推广，实际上需要自媒体带来其他传播渠道（目前常见的是通过其他微信公众号、原创微博、播客、博客等进行传播）离线二维码）。
没有任何基础的小众自媒体真的能发展得很好吗……我没有太多研究可说。
服务帐户首先是服务帐户。
其实我对功能本身没什么可抱怨的，比如微信查银行信息（招商银行）、叫出租车（XX出租车）、博物馆导览（国家博物馆）。
打印照片（打印漂亮的图片）这样的轻量级功能对于开发者来说确实很方便，而且不用花很多钱来开发应用程序。
不过，可能是一种洁癖，感觉就像桃树上长了几根杏枝。
出来的时候，我感觉有点尴尬。
然后就是微信支付。
微信买东西其实是服务号功能的延伸。
毕竟一些简单的服务能够直接支付固然不错，但是用微信就麻烦了。
感觉不好。
尤其是现在已经扩展到其他支付甚至线下支付。
（我比较喜欢专门做支付的支付宝来做这个，但是支付宝的公众号感觉不能支持。
） 游戏功能还是不错的。
它利用朋友关系来制作社交轻量级游戏。
虽然Android、iOS原生就有这个功能，但微信的好友关系信息毕竟更准确。
总体来说我觉得IM和朋友社交相关的东西还可以（虽然Android App不是很好）。
虽然其他叠加的东西无可否认是好的，但只是让人觉得别扭。
（而且如果不是腾讯，像现在这样成功的可能性很小。
） 开发者想从开发者的角度说几句话。
这方面其实更多的是开发者的贪婪而不是微信的开发架构。
问题在于服务号每月只能推送4条消息但开放接口较多，而订阅号每天只能推送一条消息但开放接口较少。
因此，你在开发过程中必须做出一些决定：是要做服务还是内容订阅。
如果开发者决心只做一个服务号，其实也能实现一些不错的功能。
如果开发者确定只做订阅号，基本功能就够了。
问题在于，我们在开发时，往往既希望服务号丰富的功能接口，又希望订阅号的推送频率。
因此，出现了一些利用各种方法在订阅账号中实现丰富功能的做法。
最常见的方法是调用Web应用程序来实现许多强交互功能，但微信内置的浏览器实际上不太好，而且还存在以下问题。
新消息来自单个线程。
我点击它后，它从旧消息跳到新消息。
读完后，无法返回到我上次查看的消息。
对于聊天来说，这并不是什么大问题。
但是对于公众号，我的文章写到一半，我的女朋友收到了一条微信消息。
我应该立即阅读吗？如果你读了，我再回来看这篇文章就会很麻烦（即使你保存下来查看）；如果你不读它，你就会有生命危险……对于上面提到的Web App来说，情况就更严重了。
跳出来之后，这些Web Apps就相当于被关闭了。
换句话说，这些Web App随时都有被其他信息打断的危险。