NiGuAnHeShang

你这个还好，我之前买了两个 cloudcone 的两个节点，这个月才是真的后悔，都连接不上去了

@wangzr 技术团最组长

看了大家的回复，我补充说明一下：我并不是认为 Go 不能开发核心业务，也不是单纯想争论 Go 和 Java 谁更好。

我真正担心的是，公司的技术选型是否与业务特点、团队能力以及现有基础设施相匹配。

我们目前做的是与金融相关的业务。公司下面的每个事业部需要相对独立地展业，同时每个事业部又有自己的业务系统，需要与总部的 SCRM 进行对接。因此，总部的系统不只是一个普通的管理系统，而是承担了客户、销售、组织、权限、业务协同和系统集成等核心职责。

同时，由于业务涉及金融产品，系统每年还需要接受审计。这意味着系统不仅要能运行，还要长期保证权限边界清晰、操作过程可追溯、数据变更可审计、系统行为可解释。

所以从系统设计和维护的角度，我更加看重的不是短期开发速度或者单纯的运行性能，而是系统未来五年甚至更长时间内的可维护性、稳定性和可靠性。

Go 的优势很明确，例如部署简单、资源占用低、并发能力强、语法相对简洁。但“语法简单”并不代表大型业务系统的工程复杂度会消失。但是我们目前仍然需要解决多租户、跨事业部数据隔离、总部数据权限、事务一致性、审计日志、链路追踪、幂等、错误治理以及第三方系统集成等问题。

Java/Spring 的优势，是很多企业级问题已经形成了相对成熟的框架、规范和实践。Go 当然也能实现，但通常更依赖团队自行建设基础组件和工程体系。

我担心的正是这一点：如果团队缺少成熟的 Go 技术积累，技术负责人也没有大型 Go 企业业务系统的实践经验，那么最后可能只是重新实现一套 Spring 已经解决过的能力，同时还要承担这些内部组件未来多年的维护、升级和审计成本。

所以我想讨论的核心并不是“Go 能不能做系统”，而是：

公司是否已经具备成熟的 Go 工程体系，自研基础组件是否值得长期维护，缺少的 SDK 和生态能力是否会持续增加成本，以及在金融业务和审计要求下，使用 Go 后的稳定性、可靠性、开发效率和维护成本是否真的优于现有方案。

如果业务以网关、长连接、推送、高并发接口和基础设施为主，我认可 Go 很合适。但如果系统核心是复杂权限、多租户、跨事业部协作、审计、报表以及大量第三方系统集成，那么我认为至少应该认真评估 Java/Spring 在长期维护上的综合优势。

大厂使用 Go 也不能直接证明普通公司同样适合，因为大厂通常拥有完整的平台工程、中间件和基础设施团队。

我承认原帖举例不够具体。我的重点不是否定 Go ，而是想讨论：对于这样一个承担金融业务、总部协同和审计责任的核心系统，在当前团队和工程基础条件下，选择 Go 是否真的是一个经过充分评估的长期决策。

@zls3201 目前 7 年 java ，三年 go 。只是在对比两个语言的技术栈和生态后得出的自己一点不成熟结论。至于你说的张口就来这个没有搞懂。我们目前开发的地方有 java 也有 go 。只是单纯对比两个语言的生态和现状得出来结论

@jetsung 目前所有模式均已经被限制了

@wat4me 两个月前还能免费使用多次，现在已经不行了

@iorilu 找资源和实时搜索比对数据能力比 gpt 好很多

@SayHelloHi 之前每两个小时重置一次访问限制，一次可以提问 2 30 次。现在只要提问一次就会提示你排队开会员。

@sddyzm 好啥哦？实时检索 xai 比 chatgpt 还厉害