golang适合做web开发吗

一、golang适合做web开发吗

1、现在都是前后端分离，语言层面就不存在模板引擎在这的差异了，剩下的最重要的无非就是效率与性能了。golang的性能自然是没话说的，而且还有非常大的优化空间，以后的性能还会提升。效率的王者无疑是php了，性能自然差了不少，当然借助像swoole这样的拓展，还是提升挺大的。golang在强劲儿性能的同时，又不失语言的灵活性，非常值得学习。web开发肯定是没问题的

2、适合呀，还适合各种分离场景，前端需要服务，还没部署，直接打个exe扔给前端运行起来就完事了，要是java啥的别的语言，还得安装环境什么浪闲的，go不需要，多方便

3、做后台有太多选择了，go不怎么擅长。但是，但是，凭借着天生的处理高并发的出色能力，做高负载高性能的rest业务处理工作那是相当的得心应手，谁用谁知道。另外，在底层业务处理方面go也能独当一面，可以抛弃c、c++了。

二、golang方向做后端服务,h5js做前端服务,哪一个容易入门,哪

1、探索后端与前端服务的入门门槛与个人兴趣导向

2、对于寻求后端开发的入门者，可能会发现后端领域与底层计算更为贴近，展现出一定的挑战性。然而，这并非意味着后端的入门壁垒不可逾越，而是对于追求深入理解计算机底层逻辑的开发者，后端服务提供了更加直接的通道。

3、未来，无论是后端的Golang，还是前端的HTML和JavaScript，都展现出广阔的发展前景。Golang以其年轻、活力和高效性能，吸引了众多开发者。而HTML和JavaScript作为前端的基石，继续引领着互联网前端技术的发展潮流。

4、在入门阶段，后端与前端服务的门槛相对较低，为初学者提供了快速上手的机会。对于那些时间充裕的开发者，不妨尝试深入探索后端与前端的领域，以发现自己的兴趣所在。兴趣是驱动个人持续进步的强大动力，找到自己的热爱所在，才能在技术道路上走得更远。

5、无论选择后端还是前端服务作为职业方向，关键在于凭借个人实力说话。技能的不断提升、实践经验的积累以及对最新技术趋势的敏锐洞察，是通往成功的关键。记住，真正的挑战在于不断学习、适应和超越自我。

三、让Golang在桌面端起飞,盘点使用Wails开发优势与不足

1、Wails，作为专为Golang开发者设计的跨平台桌面应用开发框架，无疑是Gopher们的理想选择。尽管市场上存在其他选择，但就我个人体验而言，Wails的成熟度与其他框架相比略显不足。在使用Wails开发Tiny RDM这款轻量级Redis客户端的半年时间里，我对其有了深刻的见解和感悟。

2、Wails的显著优点在于其精简的包体。得益于不包含浏览器运行时，Wails的应用包体大小轻易降至10MB以下。然而，值得注意的是，尽管体积小巧，其内存占用量并不逊色于包含浏览器的Electron类应用。毕竟，无论是基于Webview的应用还是原生应用，运行时的内存消耗相当。

3、对于Gopher而言，Wails提供了一种接近Web全栈开发的体验。如果你同时具备前端开发能力，Wails能让你在开发过程中直接在浏览器中运行代码，实现即改即刷新的高效开发流程，这对于制作小工具尤其快捷。

4、前后端自动绑定是Wails的另一大亮点。只要你声明了要导出的Go结构体实例，并编写好接口方法，Wails即可自动生成JavaScript方法声明，让你在前后端之间进行调用。无论是Go端的结构体，还是JavaScript端的数组或对象，都可以通过较为友好的方式相互转换。此外，基于通知的双端通讯实现，为频繁的数据传输提供了便利。

5、资源服务的自定义能力是Wails的一个优势。基于Web的应用框架特性，用户可以通过自定义资源路径来决定本地资源的读取路径，甚至读取远程资源文件，这一特性为资源热更新提供了可能。

6、然而，Wails的兼容性方面仍有待完善。虽然Electron类应用在跨平台兼容性上表现优秀，Wails在不同系统上的浏览器内核差异可能导致某些功能在特定版本上无法正常运行。例如，在一些旧版本的操作系统上，如部分Windows 10系统，应用可能会出现页面空白或不显示的问题。

7、运行效率方面，前后端语言不一致带来的效率损失是Wails面临的一大挑战。复杂逻辑和数据操作通常在Go端进行处理后，需要通过前后端通讯发送给前端展示，这一过程会消耗时间。在处理复杂界面时，如大量增删操作，应用可能需要拆分多次处理，这不仅影响用户体验，还可能导致应用假死或等待时间过长。

8、系统级接口的支持也是Wails需要改进的领域。相比Tauri等框架，Wails在多窗口支持和系统上下文菜单等方面的功能仍有欠缺。例如，监听主窗口尺寸和位置变化并实时保存变化值的实现较为复杂，需要借助额外的处理逻辑。

9、打包工具的完善性也是Wails的短板之一。虽然可以通过Wails CLI进行打包，但整体体验仍有待提升。在Linux平台上，打包体验甚至不如Windows和macOS。针对这些问题，如Tiny RDM的打包流程使用了GitHub Action，并参考了其他开源项目的配置，以适应不同的操作系统环境。

10、导出Web端功能的缺失是Wails的另一个限制。尽管基于Webview的应用可以提供丰富的前端体验，Wails并不支持原生导出Web版本，这在一定程度上限制了应用的部署灵活性。此外，系统接口在Web端的不支持，如文件选择对话框的打开方式，也影响了应用的跨平台体验。

11、自更新功能的缺失是Wails的又一短板。尽管资源管理器可以实现前端页面的热更新，但涉及到Go代码更改的部分仍需重新安装。随着版本迭代速度的加快，自更新功能的引入可以显著提升用户体验。官方已将此功能加入到未来规划中，预计未来会成为Wails的亮点之一。

12、插件市场的不丰富是Wails面临的一个挑战。尽管Web插件和Golang第三方依赖构成了应用生态的一部分，但与Electron或Tauri等框架相比，Wails的插件市场仍显单薄。尤其在获取系统信息、操作系统字体等关键功能上，第三方依赖的可用性和更新频率成为限制因素。

13、综上所述，Wails作为一款基于Webview的桌面应用开发框架，虽然在包体大小、开发体验和资源管理等方面有其独到之处，但在兼容性、运行效率、系统级接口、打包工具、导出Web端功能、自更新和插件市场等方面仍存在改进空间。尽管如此，Wails在不断完善中，对开发者而言，其适合快速开发小工具和非商业应用的特点依然值得关注。此外，Tiny RDM作为一款基于Wails开发的开源项目，不仅在功能上与市面上的客户端相媲美，而且在代码质量、注释和易用性方面也具有较高水准，为其他开发者提供了参考和学习的案例。