这里是全站文章的归档入口,下面是按时间倒序排列的全部文章。若想按主题浏览,请从首页的专题分类进入。
错误处理:Go 为什么不用 try-catch?
错误处理:Go 为什么不用 try-catch? 如果你来自 Java、Python 或 C 的世界,第一次看到 Go 的错误处理代码时,你大概会皱眉头: 「这什么鬼? 写了一遍又一遍,也太啰嗦了吧?try-catch 不好吗?「 别急,先别下结论。
posts
这里是全站文章的归档入口,下面是按时间倒序排列的全部文章。若想按主题浏览,请从首页的专题分类进入。
错误处理:Go 为什么不用 try-catch? 如果你来自 Java、Python 或 C 的世界,第一次看到 Go 的错误处理代码时,你大概会皱眉头: 「这什么鬼? 写了一遍又一遍,也太啰嗦了吧?try-catch 不好吗?「 别急,先别下结论。
本文使用 Go 标准库 net/http 构建一个小型 JSON HTTP 服务,讲解路由、请求解析、响应编码、中间件雏形和错误处理。
本文用并发抓取、超时取消和 worker 池示例讲解 Go 的 goroutine、channel、select、WaitGroup 和 context。
结构体与方法:Go 的「面向对象「之路 到目前为止,我们已经学了 Go 的基本数据类型、切片、map、指针。但如果你要描述一个更复杂的事物——比如一个「用户「,他有姓名、年龄、邮箱、注册时间等多个属性——用基本类型就不够用了。
小工具是学习 Go 的好方式 学 Go 不一定要从 Web 框架开始。很多时候,一个能解决自己问题的命令行工具更适合入门:代码量不大,不需要数据库,也不需要前端,但会用到文件、JSON、参数解析、错误处理和结构体建模。这些都是 Go 日常开发的基本能力。
指针:没有你想的那么可怕 提到"指针",很多人的第一反应是恐惧。这很正常——在 C/C++ 的世界里,指针确实是很多 bug 的根源:野指针、空指针、内存泄漏、缓冲区溢出……简直是一场噩梦。但是, Go 语言的指针完全不一样 。
错误处理是 Go 风格的核心部分 很多初学者看到 Go 代码里反复出现 ,第一反应是啰嗦。和异常机制相比,它确实更显眼。可是显眼正是 Go 的设计选择:失败路径应该被看见,调用者应该明确决定如何处理失败,而不是让错误从深层调用栈里悄悄冒出来。
Map 字典:Go 里的哈希表实战 想象一下你走进一家大型图书馆。你想找一本特定的书,如果一本书一本书地找,可能要花上一整天。但如果有一个索引系统——你告诉管理员书名,他直接告诉你书在哪个架子上,是不是快多了? Map(映射/字典) 就是程序里的“索引系统”。
接口不是为了“面向对象”,而是为了边界 很多人第一次看到 Go 接口,会下意识把它和 Java、PHP 或 TypeScript 的接口放在一起理解。它们确实都能描述一组方法,但 Go 接口最特别的地方是隐式实现:一个类型不需要声明自己实现了某个接口,只要方法集匹配,就自动满足接口。
结构体是 Go 里最重要的建模工具 如果说变量和函数让程序能运行,那么结构体让程序开始表达业务。用户、订单、文章、配置、任务、支付记录,这些概念都需要有名字、有字段、有规则。Go 没有传统面向对象语言那种复杂类体系,它用结构体加方法来组织数据和行为,再通过组合表达复用。
数据结构决定业务代码的日常手感 写 Go 后端时,你每天都会处理列表、键值表和文本。用户列表是切片,配置项是 Map,HTTP 请求里的路径、标题和 JSON 字段大多是字符串。语法上它们都很容易上手,但如果不了解一些底层直觉,很容易写出表面能跑、遇到边界就出问题的代码。
Go 控制流:让程序学会做选择 到目前为止,我们写的程序都是一条路走到黑——从第一行开始,一行一行地往下执行,直到结束。但现实世界中的问题往往不是这么简单的。想想你每天早上的决策过程:如果下雨了,就带伞;如果没下雨,就不带。如果今天是工作日,就早起;如果是周末,就多睡一会儿。
Go 的函数为什么让人觉得朴素 Go 的函数没有默认参数,没有函数重载,也没有把异常藏在函数体里。一个函数接收什么,返回什么,基本都写在签名上。刚学时你可能觉得它少了一些方便功能,但写真实项目久了会发现,这种朴素让调用关系更容易推理。
本文用真实业务片段讲解 Go 的变量声明、零值、常量、基本类型、if、for、switch 和作用域,帮助初学者把基础语法写扎实。
这篇 Go 入门教程从安装、命令行、main 包、go run、go build 和代码格式化讲起,帮助初学者写出第一个真正清楚、可维护的小程序。
开场:先把 SaaS 当成一种经营方式 一家三十人的培训机构,招生记录在表格里,排课靠教务老师记忆,家长沟通在微信里,收款截图发给财务。老板知道这样低效,但也担心新系统太复杂、员工不愿用、数据迁移麻烦。
开场:先把 SaaS 当成一种经营方式 一个客服主管打开系统,过去需要自己筛选差评、归类问题、分派工单。现在系统可以先整理摘要、识别情绪、推荐回复,再把疑难问题交给人工。主管并不关心模型叫什么,只关心团队是否少做重复劳动、客户是否更快得到回应。
开场:先把 SaaS 当成一种经营方式 一家公司同时使用 CRM、客服系统、财务软件、邮件营销工具和数据看板。每个系统单独都不错,但客户信息在五个地方各存一份,更新电话要改好几次,报表口径也常常对不上。工具越多,信息孤岛越明显。
开场:先把 SaaS 当成一种经营方式 一个团队做出产品后,最纠结的问题往往不是功能,而是怎么收费。按人头收,客户嫌贵;按公司收,重度客户占用太多资源;免费版太慷慨,没人升级;试用太短,客户还没体验到价值。
开场:先把 SaaS 当成一种经营方式 一个团队最初只是用在线表格收集客户信息,后来表格里出现了合同金额、身份证明、内部备注和供应商报价。工具越好用,承载的数据越敏感。等到安全团队介入时,问题已经不再是能不能用,而是谁能看、谁改过、数据存在哪里。