对于国内来说
没啥用了

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.

给嘉然打钱

没办法 国家有实名要求. 账号必须是实名的.
不过绑定移动电话号码也确实是大势所趋了. 国外的 app 也要 (例如 Telegram)

@Songxwn @dcsuibian
要不, 你们俩打一架?

@teli 为什么不建议

PowerDesigner 就可以.
你要是觉得 PD 比较古老你可以试试 Navicat. 也有这种功能.