Golang

关注公众号 jb51net

关闭
首页 > 脚本专栏 > Golang > 前端转go对比

从前端转go的一些感悟对比(附详细代码)

作者:不吃花椒的咸鱼

从前端开发转向 Go(Golang)后端开发,是一个非常可行也很实用的方向,特别是在做高性能微服务、分布式系统、云原生(如Kubernetes)等方面,这篇文章主要介绍了从前端转go的一些感悟对比,需要的朋友可以参考下

基本概念对比

不同

切片vs数组

Go的slice更像JS的动态数组。而go的数组其实是已经定死大小了的数组,不能扩容。并且在go中,大小是类型的一部分。[5]int和[10]int是两种不同的类型。

package main

import "fmt"

func main() {
	// 1. 创建一个切片 (底层自动创建了一个数组)
	s1 := []int{10, 20, 30}
	fmt.Printf("s1: %v, len: %d, cap: %d\n", s1, len(s1), cap(s1)) // len=3, cap=3

	// 2. 追加元素,未超过容量
	s1 = append(s1, 40) // 超过容量!
	fmt.Printf("After append(40): %v, len: %d, cap: %d\n", s1, len(s1), cap(s1)) // len=4, cap=6 (Go通常会按2倍扩容)

	// 3. 切片是引用类型
	s2 := s1 // s2 和 s1 现在指向同一个底层数组
	s2[0] = 99
	fmt.Printf("s1[0] is now: %d\n", s1[0]) // s1[0] 也变成了 99!

	// 4. 从数组创建切片(“窗口”的体现)
	arr := [5]string{"A", "B", "C", "D", "E"}
	s3 := arr[1:4] // 创建一个从索引1到3的切片
	fmt.Printf("arr: %v\n", arr)
	fmt.Printf("s3: %v, len: %d, cap: %d\n", s3, len(s3), cap(s3)) // len=3, cap=4 (从1到数组末尾)

	// 修改切片,会影响原数组
	s3[0] = "X"
	fmt.Printf("After s3[0] = 'X':\n")
	fmt.Printf("arr: %v\n", arr) // arr[1] 变成了 "X"
}

map

虽然几乎完全一样,但Go的map是强类型的。

在go中,map[string]int表示键是字符串,值是整数

并发编程

JS的异步主要靠事件循环。Promiseasync/await让我们以“同步”的方式写异步代码,但它本质上还是单线程的,通过任务队列切换。

goroutine是Go的并发单位。启动一个goroutine就像在JS里启动一个微任务,但它可以真正地并行运行在多个CPU核心上。

核心区别在于:

go相当于是一个拥有多个助手的项目经理。他接到10个任务,直接分派给10个助手(goroutine)。如果任务是需要动脑筋的(CPU密集型),这些助手可以同时在不同的会议室(CPU核心)里工作。此时,整个团队的CPU占用率可能是800%(8核),但报告很快就能写完,总产出极高。

JS:像一个效率极高的单核秘书。她可以同时接听10个电话(I/O操作),因为她总是在电话之间快速切换,从不让线路空着。但如果让她手写一份100页的报告(CPU密集型任务),她就得埋头苦干,其他电话都接不了了。此时,她的CPU占用率是100%(单核),但总产出很低。

更形象的类比

JavaScript 的 async/await:单线程厨房里的大厨

比如你是一个大厨,但只有一个炉灶(单线程)。

  1. 任务:你要做三道菜:炖汤(需要慢炖)、炒菜(需要快速翻炒)、蒸鱼(需要等着蒸熟)。
  2. 同步的做法:你先把汤放到炉子上,然后站在旁边一直等它炖好(阻塞)。汤好了,再开始炒菜,炒完再蒸鱼。效率极低。
  3. 异步的做法(事件循环)

async/await 的角色是什么?

async/await 并没有给你增加一个炉灶,它只是让你写菜谱(代码)的方式更优雅了。

当你写下面这样的代码时:

async function fetchAllUsers() {
  const user1Promise = fetch('/user/1'); // 发起请求1,不等待
  const user2Promise = fetch('/user/2'); // 发起请求2,不等待
  const user3Promise = fetch('/user/3'); // 发起请求3,不等待
  // 现在三个网络请求都在“后台”飞着了,大厨(主线程)是空闲的
  const user1 = await user1Promise; // 等待请求1完成
  const user2 = await user2Promise; // 等待请求2完成
  const user3 = await user3Promise; // 等待请求3完成
  return [user1, user2, user3];
}

你确实是“同时”发起了三个网络请求。这是因为网络请求这类I/O操作被浏览器/Node.js环境接手了,它们在后台进行,不占用你的大厨(主线程)。

核心结论:JS的 async/await 是【单线程】下的【并发】管理工具。它通过非阻塞I/O和事件循环,让你在等待慢速操作(如网络、文件)时,能去做别的事情,营造出一种“同时”的假象。但它始终只有一个线程在执行你的JavaScript代码。

Go 的goroutine:拥有多个厨师的厨房

现在,你升级了,开了一家大餐厅。你不再是唯一的大厨。

  1. 任务:同样要做三道菜。
  2. Go的做法( goroutine) :

go 关键字就是那个“雇佣厨师”的指令,它非常廉价,你可以轻松雇佣成千上万个厨师(goroutine)。

核心结论:Go的 goroutine 是【多线程】(M:N模型)下的【并行】执行单元。它由Go运行时管理,可以在多个CPU核心上真正地同时执行代码,尤其擅长处理CPU密集型任务。

在JS中,我们的目标是不要让唯一的线程卡住。而在Go中需要思考的是“哪些任务可以被拆分,让多个goroutine并行去跑,从而更快地完成”

JS的异步是为了不阻塞UI线程。Go的并发是为了榨干CPU多核性能,轻松处理成千上万个并发连接(如Web服务器、聊天室)。

// Go (真并发)
fmt.Println("Start")
go func() { // 启动一个goroutine
    fmt.Println("Task 1")
}()
go func() { // 再启动一个goroutine
    fmt.Println("Task 2")
}()
fmt.Println("End")
time.Sleep(1 * time.Second) // 等待一下,让goroutines有时间执行
// 输出可能是: Start, End, Task 2, Task 1 (多核并行,顺序不保证)

通信总线Channel

vue的pinia是不管对方拿没拿 只是一个公告栏

而channel就像一个带有确认机制的“快递管道”

所以,这个过程不是“发完就走”,而是 “一手交钱,一手交货”

channel <- value (发送) 这个动作会阻塞,直到另一个goroutine执行 <-channel (接收) 动作准备就绪。一旦接收方准备好了,数据瞬间传递,双方都继续执行。

写api

一般我们用node.js的时候可能会用Express搭建API,定义路由,处理请求和响应。但在go中标准库net/http自带了非常强大的Web服务器能力,不需要任何外部框架就能开始。

// Express
const express = require('express');
const app = express();
app.get('/api/users/:id', (req, res) => {
  const id = req.params.id;
  res.json({ id: id, name: `User ${id}` });
});
app.listen(3000);
type User struct {
    ID   int    `json:"id"`
    Name string `json:"name"`
}
func userHandler(w http.ResponseWriter, r *http.Request) {
    // 从URL路径获取参数
    idStr := r.URL.Path[len("/api/users/"):]
    id, err := strconv.Atoi(idStr)
    if err != nil {
        http.Error(w, "Invalid user ID", http.StatusBadRequest)
        return
    }
    user := User{ID: id, Name: fmt.Sprintf("User %d", id)}
    // 设置响应头并返回JSON
    w.Header().Set("Content-Type", "application/json")
    json.NewEncoder(w).Encode(user)
}
func main() {
    http.HandleFunc("/api/users/", userHandler) // 注册路由
    log.Println("Server starting on port 8080...")
    log.Fatal(http.ListenAndServe(":8080", nil)) // 启动服务器
}

接口

ts的接口就相当于是go的struct,而go的接口是定义行为的“契约”,一个类型只要实现了接口中定义的所有方法,它就自动地、隐式地满足了这个接口。

比如你的老板让你写一个“消息发送器”

如果没有接口

// 定义一个邮件发送器
type EmailSender struct{}
func (e *EmailSender) Send(message string) {
	fmt.Printf("通过邮件发送: %s\n", message)
}
// 我们的业务逻辑函数
func NotifyUser(sender *EmailSender, msg string) {
	sender.Send(msg)
}
func main() {
	emailSender := &EmailSender{}
	NotifyUser(emailSender, "欢迎注册!")
}

当需求变了:老板说,“我们还得支持发短信”

你加了一个 SmsSender

// 定义一个短信发送器
type SmsSender struct{}
func (s *SmsSender) Send(message string) {
	fmt.Printf("通过短信发送: %s\n", message)
}

问题来了:你的 NotifyUser 函数怎么办?应该传什么类型?

难道这样吗?

import "reflect" // 需要用反射来判断类型,非常复杂且性能差
func NotifyUser(sender interface{}, msg string) {
    if _, ok := sender.(*EmailSender); ok {
        // ...
    } else if _, ok := sender.(*SmsSender); ok {
        // ...
    }
    // ... 无尽的 else if
}
// 定义一个“发送器”的能力证书
type Notifier interface {
	Send(message string)
}
// 它不再关心传进来的是EmailSender还是SmsSender
// 它只关心:你“能不能”Send
func NotifyUser(notifier Notifier, msg string) {
	notifier.Send(msg)
}
func main() {
    emailSender := &EmailSender{}
    smsSender := &SmsSender{}
    NotifyUser(emailSender, "欢迎注册!")    // ✅ 可以!
    NotifyUser(smsSender, "您的验证码是123") // ✅ 也可以!
    // 将来有了微信发送器
    // wechatSender := &WechatSender{}
    // NotifyUser(wechatSender, "您有新的订单") // ✅ 还是可以!
}

struct vs class

// JavaScript Class
class User {
  constructor(name, age) {
    this.name = name;
    this.age = age;
  }
  greet() {
    console.log(`Hello, I'm ${this.name}`);
  }
}
const u = new User("Bob", 40);
u.greet();
// Go struct and method
type User struct { // 定义数据结构
	Name string
	Age  int
}
// (u User) 是接收者,表示greet方法属于User类型
func (u User) Greet() {
	fmt.Printf("Hello, I'm %s\n", u.Name)
}
func main() {
	u := User{Name: "Bob", Age: 40} // 创建实例
	u.Greet() // 调用方法
}

Go将数据和行为更清晰地分离开。struct只管数据,方法只是恰好接收这个struct作为第一个参数的函数。这使得组合优于继承的设计模式变得非常自然。

总结

到此这篇关于从前端转go的一些感悟对比的文章就介绍到这了,更多相关前端转go对比内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

您可能感兴趣的文章:
阅读全文