至于 Node 全栈, 这个据我个人了解, 用 Node 全栈的公司不多.

不算是什么好方向. 应该说软件开发 (IT) 都不算是好方向.
如果你不准备出国, 那么唯一的好方向就是考公务员.

---

如果你就一门心思还是准备做开发的话. 全栈几乎是必然的.
如果你确实很屌很牛逼 985 / 211 本科毕业 + 985 / 211 研究生以上, 阿里腾讯字节华为等大厂 offer 随便挑, 那你确实可以专精前端 / 后端. 这些大厂基本上进去从入职到离职基本上就只干一个活儿.

如果你不是, 那全栈不是好不好方向的问题. 是必然的问题.
事实上是: 中小型企业普遍不分前后端. 基本上招进来之后就是从 css 到 k8s 全干.

后端的话建议就认真学好 java 跟 java 相关的 SpringBoot, Spring Cloud, Dubbo 等. 以及 Docker, Docker Swarm, K8S, ELK, 等. 前端 VUE 跟 React. 有多余的精力可以学一下 C/C++.

至于 GO 等其他开发语言都不建议深入学 (感兴趣除外).
比如 C# 现在岗位少, 工资低, 除了外企以外基本没有大厂在用.
比如 GO 基本上用的都是大厂, 拿来魔改 K8S, Docker 等. 学 GO 能顺利找到工作的大前提基本是 985 / 211 本科毕业. 如果你不是就不建议学 GO.

还有一个方向是鸿蒙开发. 鸿蒙宣布不再兼容 Android 之后有不少大厂高薪招聘鸿蒙开发工程师. 这可能是个风口.

一个是很多软件不是只做信息展示而已. 而且还要做很多浏览器无法实现的功能. 例如文件的读写, 调用本地程序, 跟硬件交互等. 例如 QQNT 就是. QQNT 的底层是 C++ 的, 只有展示层是 Electron. 这就涉及到大量的 ffnapi 操作. 浏览器怕是无法实现的.

另外很多 Electron 程序也是涉及到跟硬件驱动跟硬件 SDK 交互的 (如扫描仪, 打印机, 工控设备, 锁控板等), 纯浏览器是很难实现甚至可能无法做到的.

@forgottencoast PHP 基本上全都转 go 跟 java 了. 市面上已经见不到多少 PHP 的岗位了.
而且桌面端现在也是可以用 Electron 做了. 对性能没什么要求的用 Electron. 有要求的用 QT. Electron 只要招前端开发就能做. 招聘压力比 C# 小太多了. 所以桌面端 C# 其实也不吃香.

对于国内来说
没啥用了

Java 的生态已经稳固了. 而且技术圈子往往是极端封闭的. 现在 90% 的非 .NET 码农可能都不清楚 .NET (.NET Core) 跟 .NET Framework 的区别. 这些码农进入管理岗之后就更不可能让技术栈变成 Java 了. 一些空降过来的 CTO 甚至可能还会出于方便自己管理的原因反向升级让已经运行得好好的基于 .NET Core 技术栈开发的产品逐步向 Java / Go 迁移. 更别提很多早期的 .NETer 们可能现在还抱着对 .NET 技术框架的恶劣印象而拒绝 .NET Core 跟 .NET 6/7/8.

这种马太效应会让 .NET 的市场越来越小. 实际上这种情况已经发生了. Javaer / Golanger 越多, Java / Go 的岗位越多, Java / Go 的岗位越多, Javaer / Golanger 越多. 反观 .NET, .NETer 越少, 招 .NET 的越少. 招 .NET 的越少, .NETer 越少. 甚至有些公司已经到了因为 .NET 人才供应跟不上而不得不转其他技术栈的地步了. 估计用不了多久, .NET 在中国大陆就会绝迹了吧.

电脑端: Telegram, Navicat, 网易云音乐, Chrome, QQ (新), Notepad3, Tortoise 系列, VSCode
手机端: Via, JuiceSSH

额, 首先 Clash 的 GUI 是 Electron 开发的... 不是 golang. 核心的那个命令行工具才是 golang 开发的...

其次 golang 现在就业情况非常窘迫. golang 学下来可以做的岗位基本上都是 DevOps 或者基于公司业务需要对 Kubernetes, Docker 之类的东西进行魔改. 而能上这些系统的基本都是大厂. 中小厂用 golang 做业务的不多, 基本上都是 Java. 基于各大厂对学历的严苛程度, 如果你学历不是特别好, 学 golang 找工作会非常费劲.

当然, 如果是作为爱好, 学个 golang 挺好的. 艺多不压身嘛.

不一定.
图方便的话登录之后给返回用户信息没毛病.

但是如果按照接口职责单一原则, 用户信息接口单独获取也无可厚非.

@lujiaxing 再不就是系统里不当使用了 dynamic 类型

@BeautifulSoap 除非你们其中某一个微服务子系统是用弱类型语言开发的 (Javascript), 否则不可能出现 "某一种情况下有这个字段另一种情况下没有这种字段" 的离谱情况. 如果缺字段, 应该是在测试阶段就已经发现了. 毕竟缺字段会导致整个程序跑不通. 我不明白你们公司的业务是怎么搭建的, 怎么测试的, 怎么可能出现其中一个微服务没有按照约定返回字段却顺利通过了的 codereview, ut, 集成测试的.....

@BeautifulSoap 那我就要问问了, 测试干嘛去了. 上线前不做集成测试的么? 怎么可能出现两边接口对不上的问题?

而且如果你要是真对自己团队的成员都如此不信任的话, 那我就只能建议你放弃 json, 改用更加严格的 SOAP 或者 GRPC 了. 那玩意不用校验, 说好的字段缺一个字都会炸.

@BeautifulSoap 对于值类型 (或称原子类型) JSON 字段的 NULL / Undefined 的解析就应该解析为类型默认值. 即: 0.
这是这么多年约定俗成的要求, 也是标准做法. 没什么可争论的. 说了好几遍了 "后端不能信任前端/外部接口传来的数据". 你自己不做数据合法性校验难道还赖前端不给你传么?? 没人说你一定要把 DTO 里改成指针, 你可以不改啊, 但是你代码逻辑肯定要判断啊, 尤其这种支付的场景, 前端本就不该把金额传给你好不好? 标准做法应该是只给你传一个订单号, 以及用户在支付平台扫码得到的 AuthToken... 金额/SKU 摘要/标题等是要你从订单里翻出来的!! 哪儿有前端告诉你是多少钱就是多少钱的道理?

这玩意多得很. 很多医疗系统, 工控系统都是 WinForm 的. 甚至有不少客户用的还是 Windows XP. 你不用 WinForm 准备拿什么玩意给他们用...

不过现在很多都已经转 Avalonia / Uno 了. 毕竟信创嘛, 总要考虑那些统信之类的 Linux 环境的.

@kumoocat 其实这种在 C# 里就很好解决. C# 里对于值类型有 Nullable<T> 包装类, 简化为 "-?", 如: Int32? Color? 等.
如果觉得某个值不应该为 NULL, 要么把对应字段改为 Nullable 类型即可. 这样遇到相应字段不存在/null 的情况下, 反序列化回来的就绝不会是默认值了.

或者更进一步在对应的 Property 上加 [JsonRequired] Attribute. 反序列化发现空值直接报错.

搞什么鬼? JSON 本来就是非严格结构好不好? 经常会有 A 跟 C 对接, A 提供 a, b, c, d 字段但是 C 接受 b, c, e, f 的情况. 毕竟 C 可能还要接 B. 所以遇到 "C 接 A 的时候 e, f 没有值, 接 B 时候 b 没有值" 是极其正常的情况.

如果你觉得这种出现默认值的情况不合理, 要么要求调用方修改, 要么自己在代码里做 Guarding.

要么就不要用 JSON 改用 SOAP XML.

给嘉然打钱