Go 1.22 新特性：range over integers 和 math/rand/v2
深入探索 Go 1.22 的重要特性：range over integers、math/rand/v2 包、ServeMux 路由增强、性能优化与迁移指南
posts
Posts
Skynet Lua API 参考手册
Skynet 提供了丰富的 Lua API，让开发者能够方便地使用框架的各种功能。本手册将详细介绍所有常用 API 的用法、参数和返回值。核心模块 require "skynet" 这是 Skynet 的核心模块，提供了所有基础 API。
游戏服务器从模块化单体到服务化架构
很多游戏服务器不是一开始就需要微服务。项目早期，玩法还在变，团队人数不多，模块化单体往往更快也更稳。真正的问题不是单体，而是没有模块边界的单体。等玩家规模上来、团队扩大、活动频率变高，如果早期边界清楚，就能自然拆服务；如果早期所有逻辑都粘在一起，后面拆分会像拆炸弹。
Go 泛型入门：从重复函数到类型参数的自然过渡
泛型不是为了把所有代码都写成抽象 Go 很长时间没有泛型，所以早期 Go 代码大量依赖具体类型、小接口、函数参数和适度重复。后来 Go 加入类型参数后，很多重复工具函数终于可以写得更自然，比如 、 、 、 这类集合操作。但泛型并不意味着所有代码都应该泛型化。
Skynet 消息传递机制
Skynet 的消息传递机制是框架的核心，决定了服务之间如何通信。本教程将从底层原理到上层应用，系统讲解 Skynet 消息传递的方方面面。消息传递概览 在 Skynet 中，所有服务间的通信都通过消息完成。消息传递具有以下特点： 1.
SaaS 创始人销售剧本：从随缘聊天到可复盘成交
开场：创始人销售不是“能聊就行” 很多 SaaS 早期成交都来自创始人亲自销售。创始人最懂产品、最懂客户现场，也最能临场解释。但问题是，如果每次销售都靠临场发挥，团队就很难知道为什么某些客户成交、为什么某些客户流失、哪些话术有效、哪些客户根本不该追。
Skynet 服务模型详解
在 Skynet 框架中， 服务（Service） 是最基本的运行单元。理解服务模型是掌握 Skynet 的关键。本教程将深入讲解 Skynet 服务的生命周期、服务类型、创建与管理方式，以及服务间的依赖关系。
SaaS 行业观察：AI Agent 的崛起与自主工作流革命
当 AI 不再只是"助手"，而是"同事" 2024 年 1 月的一个周一早晨，一家中型营销公司的运营总监李明打开电脑，发现了一件令人惊讶的事情：他的 AI Agent 已经在他睡觉时完成了三项重要工作。
Skynet 安装与环境搭建
本教程将详细介绍如何在不同操作系统上安装和配置 Skynet 框架，并编写第一个 Hello World 服务。系统要求 在安装 Skynet 之前，请确保你的系统满足以下要求： 操作系统支持 - Linux ：Ubuntu 18.
Steam 审核被退回怎么办：商店页与构建返工实操手册
先把退回当成流程，不要当成否定 Steam 上架过程中，商店页或构建审核被退回并不罕见。对第一次发行的个人开发者来说，这件事容易带来情绪压力：页面已经宣传，Demo 已经准备，发售日期也写进日历，突然收到反馈，第一反应往往是“是不是平台不让发”。
Skynet 简介与核心概念
Skynet 是由云风（吴云洋）开发的一款轻量级、高性能的游戏服务器框架。它采用 C 语言编写核心，使用 Lua 作为业务逻辑开发语言，基于 Actor 模型实现并发处理。自 2012 年开源以来，Skynet 已经在众多游戏公司和互联网公司的生产环境中得到验证，成为国内最流行的游戏服务器框架之一。
Go HTTP Basic Auth 入门：用中间件保护内部页面
很多小型 Go 服务都有一个内部页面：查看任务队列、触发一次同步、检查缓存状态。它不一定值得接入完整登录系统，但也不能裸奔在公网。HTTP Basic Auth 是一个简单选择。浏览器会弹出用户名密码框，请求头里带上凭据，服务端验证后再允许访问。
2023 年 Go 语言年度回顾与展望
2023 年 Go 语言年度回顾与展望 2023 年是 Go 语言发展历程中非常重要的一年。从 2009 年开源至今，Go 已经走过了 14 个年头。这一年，Go 发布了两个重要版本（1.20 和 1.21），生态系统持续壮大，社区活跃度再创新高。
从 Demo 到正式发售的 Steam 更新漏斗：个人游戏如何不丢掉早期关注者
Demo 结束不是漏斗结束 很多个人游戏在 Demo 发布时获得一波关注，愿望单涨了，反馈也来了。然后项目回到开发，页面几个月没有更新。等正式发售时，早期试玩玩家已经忘了游戏，或者不知道正式版相比 Demo 改了什么。Demo 到发售之间的承接，是个人开发者常忽略的漏斗。
游戏服务器运营回滚控制架构设计
问题背景 LiveOps 时代，服务器每天都在变。活动开关、奖励倍率、排行榜分组、商城礼包、关卡掉落、运营脚本都可能在线调整。真正危险的不是变更本身，而是变更缺少控制面：谁改了什么，影响哪些玩家，能不能预演，出错后回滚是否会造成二次发奖。运营回滚控制架构的目标不是阻止变化，而是让变化有轨道、有刹车、有行车记录仪。
SaaS 路线图取舍：需求很多时先做什么
开场：需求越多，越需要拒绝机制 SaaS 早期最开始怕没人提需求。等客户多起来，又会怕需求太多。销售说这个客户要集成，客服说那个客户不会用，老客户要报表，新客户要模板，开发还想重构，系统稳定性也需要补。
Go 配置校验入门：让服务启动时就发现问题
配置错误应该在启动时暴露 很多线上问题不是代码逻辑错，而是配置错：端口写错，数据库地址为空，第三方 API URL 少了协议，生产环境打开了调试开关，超时时间是 0。最糟糕的情况是服务启动成功，直到请求进来才暴露配置问题。
Steam 发售后更新与长尾运营：让独立游戏持续被发现
发售后才是真正的运营开始 很多独立游戏把所有精力押在首发，发售后看到销量回落就失去方向。实际上，Steam 上的游戏很少只靠首日决定全部命运。首发当然重要，但发售后的补丁、评价、折扣、更新、活动和页面维护，会共同决定长尾销售。
Go 子测试组织入门：表驱动、t.Run 和测试命名怎么写
Go 的测试工具很朴素，没有复杂的断言 DSL，也没有必须学习一整套框架的压力。你只要创建一个 文件，写一个 ，再运行 ，就已经能开始了。也正因为它朴素，很多初学者会在项目变大后遇到另一个问题：测试越写越散，失败信息不清楚，新增一个场景要复制一段函数，最后大家都不太愿意补测试。
游戏服务器端到端可靠性架构设计
端到端可靠性不是某个组件的能力，而是一条链路的能力。玩家点击领取奖励，请求经过客户端、网关、业务服务、数据库、事件、资产、邮件、客户端同步和客服查询。任何一环没有幂等、没有日志、没有恢复，最后都可能表现为“奖励没到账”。