这种就是传统思维下的历史成本
不愿意抛弃已有的认知去学习新的东西
------
当然，你用已有的知识去学习新东西是可行，但前提你得懂什么叫『抽象化』什么叫『融会贯通』（当然这个词选得不好）
大概例子就是，比如你已经 [精通] 一门乐器，那你再学习另外一种 [同类型] 的乐器时，那你以往的知识就是有帮助的
或者如果你掌握都是 [通用] 的 [方法论] ，那你学习什么都用得上。比如如何快速阅读一本书
否则你只会被你以往的经验束缚，并且可能走错方向
-----
当然额外的说明
像这种很 [通用] [现代] 的技术，或者 [新] 的技术方案，入门门槛难道会变得更难？
如果更难，那不就退步了？
或者说，如果你让一个没接触的人去学习，你会发现他学习非常的快
估计是上面有要求
如果你提交多一点领导也好看一下
拿到老板面前也好说
只能说以前受限于用户环境兼容，包括现在也是
实现对接 grpc 本身很简单，就是基于 http/2 传输
但是基础环境跑不起来，还得考虑降级等操作，那这部分肯定费时费力
那么就需要大厂来搞和实现
所以需要一点时间慢慢来，这就和短视频和网络关系一样，你网络没升级，短视频肯定不行
国内微服务框架
阿里 dubbo-go
头条 kitex
腾讯 tars-go
b 站 kratos
我们最后选择了 kratos，原因
- dubbo-go 感觉被名字局限了，毕竟是 go 版的 dubbo，而不是 go 版的 spring 。当然 dubbo-go 也是朝着更多功能扩展，但感觉还是怪怪的，期待再独立一个项目出来。但是毕竟阿里还是 Java 为主，Java 生态无敌
- 腾讯，每次都让人有种格格不入的感觉，但是确实这里做的最『未来』的，整体性很强。还有一个原因虽然和 tars 没关系，但是微信开发团队真的非常糟糕给腾讯名号蒙羞
- 头条，没什么感觉也没什么推广
- b 站，有概念感、业务实践、也喜欢毛剑老师。唯一缺点就是 git 社区客服戾气太重，有点玩不起的感觉，不知道是不是 b 站人员，可能是最近生活不顺利啥的。
然后为什么要框架，其实如果你只是写『脚本』那完全不需要
但是如果你需要架构层面，那肯定需要这类框架，rpc 框架现在基本都是往 go 框架发展
为什么选国内框架
- 中文太重要了
不知道是你们公司架构的问题还是你理解的问题（因为初期的表现确实就是个数据库增删改查的接口封装）
一般架构思想其实很简单，就是
原来都是单体应用，维护麻烦，崩得也很彻底
维护麻烦怎么办？拆应用呗，1 个单体应用拆成 5 个业务应用，每个业务应用还可以不同人维护，这样不就解决了。
---------------
我们知道了用拆可以解决问题，那理论上拆得越多问题解决越彻底，当然这肯定有副作用（需要自己权衡）
--------------
而你遇到的问题其实在于怎么拆？
如果仅仅只是把数据库的读写拆出来，那这个肯定是很无语的，因为根本没有解决问题
你有其他语言基础 理论上学习其他语言应该没什么问题 你需要的可能是实践是吧
实践的直接去极客时间或者 b 站看就行，其实内容不多（除非你要连微服务一起看了），几个小时就可以了（当然大部分视频都是废话或者广告）
然后目前我们公司实践下来，最后还是 kratos 生态一把梭
毕竟
1. 是 b 站的，有真实大量业务实践
2. 是国内的，无压力
3. 负责人很有趣
不过 go 的工具生态真的很糟糕就是了，像我们以前用 java 和 nodejs，java 是全，nodejs 是快
go 现在连个真正的 orm 工具都没有，框架更惨，还在 cli 生成文件的阶段
搞得比较 JavaScript 更像脚本语言 很无语
我现在的看法就是
php：如果是小公司（不管规模大不大），或者是个人网站编程爱好者，那非常的合适，简单生态丰富，就是你去捡垃圾拼起来也能跑
nodejs：前端必备，因为以前很多情况下后端同学是不乐意去做一些非『重要业务』的事情。加上现在 serverless 解决了运维的问题，那对于前端来说简直不要太爽。
后端呢？性能和线程是大问题，所以大公司肯定是不会用，还是只能拿来个人自己玩玩
go：还没开始实践之前，我的想法是 go 因为是新语言没有历史包袱，而且很多特性都是非常符合未来发展的。
当我实践以后，发现这玩意根本满足不了期望
你说想要简单，你和 java 比，其实其他语言也很简单。语法简单，大家都差不多，方法简单，其他语言封装一下也差不多。所以这个真没什么特别大作用
你说想要性能，JAVA 肯定更好
最重要的是生态，Java 一套 Spring 干趴所有人，特别是大公司的需求
然后 php 有国内无敌的生态，nodejs 有无数造轮子的人，基本上生态也很好
而 go 生态真的太烂了
除了 b 站七牛在硬推，真的差强人意。
详细的说
对于单体应用
最重要就 2 个东西，web 框架和 orm 工具
web 框架就是简易
orm 工具都不能说简易，gorm 和 xorm 真的都称不上 orm 工具
对于什么微服务、云原生
rpc 通信，大家都有啊
所以 go 的场景真的很尴尬，我觉得很噱头还不如其他语言(各种非主流语言)
总之，如果你想要当一辈子的程序员，或者想去大厂混几年，那选 Java 肯定没错，毫无疑问
其他情况的，随便了
腾讯广告的设计我觉得真的是在国内 B 端最顶尖的水平
有没有什么公众号或者途径可以关注一下？
设计失误就是设计失误
垃圾就是垃圾
搞得乱七八糟
现在很蛋疼 合并以后 麻烦事更多了 就是气死人
我 19 年 16 寸 然后使用绿联 DP => typeC 结果就是只能 720p 60hz
然后多插几次就有可能出现 1080p 60hz 可以说非常蛋疼
而且不确定是不是接入外接显示器后，电脑风扇就是一直 5000 转，然后 60℃
太蛋疼了
我看到有个小程序叫「房间搜索」，可以搜索到 clubhouse 的房间。感觉这个功能比较有用
Api 文档一般有几类
1. Json => 自动生成文档类，例如 apiary/coding
2. 注释 => 自动生成文档（不推荐）
3. 调试主导类，例如 rap2/postman
4. 自成一派，例如 swagger
5. 文档主导类，应该就是 easyDoc 了
当然还有一些山寨货，例如 apizaza，还有一些 postman 山寨品，就是山寨还敢收费的那种
目前还在用 YApi，基本能满足 80%的需求
而比较看好的是 Rap2，有一些针对开发者更友好的功能
但是上面这两个玩意太开发者了，写文档其实很不舒服
所以看有没有更好的，楼主这个 EasyDoc 产品就是交互增强版，确实是能解决一部分需求。
但整体来说还是都没能解决的很完整。
但是这种工具吧，自己写耗时耗力，用热门的呢，要么国外慢的要死，要么国内又丑又难用
非常烦恼
然后回过头来想想到底需求是什么？
80%解决开发对开发间的问题
- 接口文档
- 接口调试
- 非必须 - Mock
能满足这些已经足够了，所以综合起来还是 YApi 更好一些，不仅开源基础功能全都有
但是要是有能解决另外 20%的产品那就更好了
而 EasyDoc 却走的是另一个方向，即不是在 YApi 上扩展解决剩余 20%的需求。而是走了另一条路，这就导致那 80%的都没做到很好
但是如果要选择二次开发，肯定还是 Rap2
还有另外一个问题，就是产品稳定性，YApi 和 Rap2 至少是有大厂支持的，其他产品都是一些韭菜拖着。
特别像这种工具，我说过解决 80%需求已经够了，所以除非你做得很好，否则根本就是瞎折腾
能看得出 EasyDoc 目的和做法是很好的，可不知道能走多远。考虑到团队因素。
除非 EasyDoc 开源，否则一般团队应该是不敢用的。
看你有没有时间学习
有就学 Flutter，一劳永逸
没时间就学 React-native + Taro
傻子才选 Uni-APP，什么都最差，又没有未来。除非你一个人接外包用
哎，太难了
首先，对于小的创业公司
1. 免费版根本不够用，不然也不会去看付费版。除非你们公司就 1 个项目...
2. 最低付费是 20 人的套餐，每年 2000 块，不要看什么人均，月均这么傻的心理安慰。我们团队就 7 个人，在这个工具上 1000 以内的成本才能接受。况且还有其他费用。然后其他就不用付钱了吗？
其次，对于替代品
1. 国外的，满足需求。但是更贵而且还要经常翻墙。效率降低太多
2. 国内的，真的没有啊。像慕客这种完完全全 80 年代程序员风格产品..实在不敢恭维。和蓝湖大概相差 20 年的差距。就算免费有什么用... 不好用就不是不好用
如果从'写代码'的层面去看，前端确实远远比不上后端的完善。而如果这讨论这个方向，楼主说得都没有大问题
嵌套真的太痛苦，前端用户 html + css3 写的话，把视图分出去写，熟练的话，速度特别快，基本 1 小时就搞定。
配合 jsx 的话，可以做到很好的代码分割。
但是 Flutter 的无限嵌套真的噩梦啊、毕竟显示需求一个页面可能达到几百层嵌套，我的天，我快看哭了。而且不够灵活，一个 flex 我要写一堆嵌套，真的尼玛
以前一个页面，设计还原 1 小时，逻辑 1 小时。现在设计还原 1 天，我的天啊
Select Language