楼主这个情况我觉得可以考虑深入学习 Node.js 。Midway 、Nest 搞起来。

来点新鲜的玩具：

Compose Multiplatform:
https://www.jetbrains.com/zh-cn/lp/compose-mpp/

React Native:
https://microsoft.github.io/react-native-windows/
https://github.com/nodegui/react-nodegui
https://github.com/infinitered/reactotron

Rust:
https://tauri.studio/
https://slint-ui.com/

如果是真的生产级应用还是用点稳定的技术。
写过 C# 再去写 C++ 简直是折磨吧。
目前 C# 比较稳定的桌面框架也就：
https://platform.uno/
https://avaloniaui.net/
坑多不多我自己也没用过也不清楚。不过话说哪个框架没坑呢？办法总部困难多。

单纯就业的角度来说 Java > Go > PHP > others

不过我觉得是，如果你花三四个月深入学一下门槛比较高的 Rust ，回头只要花一个星期就能掌握 Go 了。
我比较推荐掌握三种语言：

第一类短平快工具型语言：F#、Python 、JavaScript 、matlab 。代码简洁，写起来十分顺畅，适合平常自己写脚本整点小工具。

第二类偏向系统的底层语言：Rust 、C/C++、汇编?。这类语言可能稍微有点难度，但是能帮助理解硬件和操作系统的运行逻辑，非常适合用来提升。

第三类工程型语言：C#、Java 、TypeScript 、Kotlin 。这类语言通常语法比较严格，而且是面向对象的，非常工程化。搭配合适的框架很难能避免产生垃圾代码。这类语言用来讨碗饭吃。

我还是想再谈谈 Go 语言。Go 语言为了追求易学，有意向短平快靠拢，这导致语言过于简陋，是真的简陋：
为了省 throw/try ，靠 return 来传递错误；不健全的类型系统，interface {} 满屏飞。
我感触比较深的 ORM 场景。看看 C# 的 Entity Framework ，兼顾了代码简洁和类型安全。Go 的 ORM 要么只有简洁(gorm)，要么只有类型安全(ent)。说到底还是 Go 语言从根本上设计有问题。
在我有限的认知里，Go 语言是最丑的编程语言了。

相比于 Go 我觉得合适 Rust 更优雅一点。
语言设计上 Rust 完胜 GoLang 。
而且 Rust 是更底层的语言，经常写 Rust 能帮助你理解硬件的运行逻辑。
相比于 C/C++，Rust 的语法更加现代，有健全的包管理和构建工具。

正好最近在做的项目前后端深度使用 GraphQL 。

优点：
1. 强类型文档。GraphQL 本身首先是一门语言，而且是强类型语言，目前社区已有各种语言与 GraphQL 转换的工具。实践中，前端配合自动生成工具和 TypeScript 能确切知道每个 Query 每个变量每个属性的类型，省去了以往 RESTful API 项目中前端手动声明类型的麻烦。使用如果后端使用 TypeGraphQL 或者 NestJS 这类框架，能直接从 TypeSCript 的 Class 生成文档(schema)。

2. 自动聚合。以往 RESTful API 的每个接口的数据都是预先设计好的，前端展示的数据和后端返回的数据有时匹配不上，复杂的业务往往需要一层 BFF 层来做数据聚合。GraphQL 的返回数据是由前端决定的，能有效降低前后端的数据耦合程度，并且减少接口调用次数。

3. 更细致的鉴权。RESTful API 的鉴权颗粒度只停留在路由上，但是 GraphQL 能控制每个字段的访问权限。（讲道理 RESTful 也能，无非实现起来麻烦点）

缺点：
1. 迁移成本高。
2. 生态不完善。如果后端要用 GraphQL 的话目前几乎只能选 Node.js 了。其他语言生态都不完善，缺少 dataloader 、federation 等关键包库。
其他方面我觉得和 RESTful 相比，GraphQL 简直完胜啊

坑：
1. 著名的 N+1 问题。对于后端来说，需要对每一个列表查询进行优化避免 N + 1 。目前流行的解决方案是 dataloader 。
2. 每个前端项目只能有一张 GraphQL schema 。这使得后端必须部署一个网关来整个各个微服务，目前几乎只能用 Apollo Federation 来解决这个问题。
3. Subscriptions 。Apollo 实现了 Subscriptions 功能来帮助服务器主动发送消息。但是实践下来发现这个功能还是比较简陋的，不合适微服务架构和集群部署。

后端后期换 Go 我不是很理解。
在我看来 TypeScript 比 Go 优秀太多了。
Node.js 的生态与 Go 也是不相伯仲。另外看到前端有用 GraphQL ，那么后端用 Node.js 的 TypeORM/prisma + TypeGraphql/Nest.js 基本上是最优解。Node.js 关于 GraphQL 的生态比 Go 要领先一大截。
Go 比 Node.js 唯一优势就是性能，不过这一点只要多堆点机器就能解决了。
如果是要提升自己的话不如练练 Rust 。

语雀

@Chism #5
个人感觉 Vue 3.0 的数据更新机制比 React 好太多了。
React 因为它函数式编程的思路，每次数据更新都要重构组件。这就要求开发者需要手动权衡组件更新的开销对其进行优化，体现在代码上就是到处 memo 、useMemo 。
而 Vue 3 是通过 Proxy 监听依赖变化，数据更新时不必重构整个组件，通常不需要开发者手动优化，写起来顺畅多了。

如果要深耕前端的话，React 是必学的。
单纯做项目小而美的 demo 项目的话，目前 Vue3.0 就是我最心悦的框架了。

有一说一，Go 语言设计的真不怎么样

感谢楼主，mark 一下

个人推荐 Flutter

目前而言 RN 的生态比 Flutter 其实略逊一筹，阿里云腾讯云的很多服务会提供 Flutter 、iOS 、Android 的 SDK 但没有 RN 的 SDK 。Flutter 的开发的移动端应用目前能直接跑在 Web 端上。
Flutter 坑很多，听说 RN 坑更多。
《哔哩哔哩漫画》所有页面都是用 Flutter 开发的，流畅度非常不错。
另外是个人觉得 React 的函数式数据更新思路很奇怪，后来的 vue3 、solidjs 、Flutter 的 GetX 都没有采用 React 的函数式 + Hook 的思路，代码写起来顺畅多了。

我个人感触比较深的是 ORM 场景。C# 有 Entity Framework 、TypeScript 有 TypeORM 、MikroORM 、PHP 有 Eloquent 、Kotlin 的 Ktorm 。看过了以上 ORM 再看 Go 的 ORM 实践就很一言难尽。

优雅的 ORM(TypeORM)是这样的：
```
const article = await articleRepository.findOne({ title:"Tales of Ten Worlds"，published:true });
```
从 文字表里取一篇文章，取出来的变量直接从 findOne() 函数里传出来，非常顺畅。

Go (gorm) 语言是这样的：
```
var article Article
db.Where(&Article{Title: "Tales of Ten Worlds", Published: true}).First(&article)
```
先声明 article 为 Article ，再传指针到 First() 里，一下子打破了函数式编程的 「没有"副作用"」「不修改状态」的教条，这里将 article 的类型改为其他也不会有编译时错误。

或者这样(ent)的：
```
article :=client.Article.Query().
Where(article.TitleEQ("Tales of Ten Worlds"),article.PublishedEQ(true)).Limit(1)
```
这样确保了编译时类型安全但将查询条件改成了指令式的罗列，损失了简洁性。

GraphQL 大法好 https://graphql.cn/
GraphQL 就没有 get 、put 、delete ，全是 post ，根本不纠结。

有一说一，Go 语言是真的破烂。

拿 ORM 场景举例来说。
正常(TypeORM)是这样的：
```
const article = await articleRepository.findOne({ title:"Tales of Ten Worlds"，published:true });
```
从 文字表里取一篇文章，取出来的变量直接从 findOne() 函数里传出来，非常顺畅。

Go (gorm) 语言是这样的：
```
var article Article
db.Where(&Article{Title: "Tales of Ten Worlds", Published: true}).First(&article)
```

先声明 article 为 Article ，再传指针到 First() 里，一下子打破了函数式编程的 「没有"副作用"」「不修改状态」的教条，这里将 article 的类型改为其他也不会有编译时错误。

或者这样(ent)的：
```
article :=client.Article.Query().
Where(article.TitleEQ("Tales of Ten Worlds"),article.PublishedEQ(true)).Limit(1)
```
这样确保了编译时类型安全但将查询条件改成了指令式的罗列，损失了简洁性。

Go 语言自身的缺陷也是对开发者的限制，比如 Go 语言的 ORM 和 C#、php 、TypeScript 之流比就显得 too simple 。

小孩才做选择，大人 CSS In JS 、Utility CSS 全都要

https://fower.vercel.app/zh-cn/
https://xstyled.dev/

如果要支持 node.js 和 php 的话只有 dtm 了
https://github.com/dtm-labs/dtm

关键词：分布式事务
常用实现：AT 、TCC 、SAGA

https://seata.io/zh-cn/blog/tcc-mode-design-principle.html