一条 Go 语言产品线的成长
这是一份属于华北电力大学 iDealStudio 工作室的成长记录：2019 年，一支 Go 语言学习小组起步；2020 年做出第一个开源项目；2023 年 Fast-Https 正式立项；2024 年发布 1.0.0，并入驻华为 openEuler 社区。向下滚动，按时间顺序看这条产品线如何一步步长出来。
开启 Go 语言产品线
一个技术方向的选择，往往比一个功能更早决定后面几年。
2019 年，工作室把 Go 语言定为长期投入的技术方向，同时开出一条独立的产品线：不只是学语法，而是用这门语言真正做出可以交付的东西。对一支学生团队来说，这个决定意味着放弃"什么热就做什么"，转而在一个方向上反复积累。
软件 1901 班的李瑞阳成为第一批 Go 语言学习成员。他从零开始啃语言规范与并发模型，把学到的东西写成工作室内部可以复用的示例。如今他已毕业、在华为西安工作，而这条产品线仍沿着当年打下的底子往前走——最早的一批人，成了这条时间线的起点。
学习小组与首个开源项目
从"一个人学"到"一群人做"，第一次把内部痛点做成对外开源。
这一年成立了 Go 语言学习小组，张亿贺、彭博、刘浩宇陆续加入。学习方式从各自看书变成一起读代码、互相评审：谁写的并发逻辑有问题，就在例会上摆到桌面上讲清楚。团队的技术共识，基本是在这些争论里长出来的。
4 月，小组发布「Go 语言接口代码生成器」——把重复的接口样板代码交给工具生成，让开发者只关心业务本身。这是团队第一次把日常开发中的麻烦整理成一个能被别人使用的小工具。同年，由刘浩宇负责申报 Go 语言大创项目，项目制带来了稳定的研究周期与经费支持，“做项目—出成果—再投入"的循环就此成型。
基于 IPFS 的去中心化 Blog
换个问法：内容为什么一定要放在别人的服务器上？
张亿贺负责开发了一款使用 Go 语言、基于 IPFS 的开源 Blog 发布系统。它把文章内容做成内容寻址的区块，发布与读取都不再依赖某台中心服务器，因此可以构建出一套无服务器、去中心化的发布与管理方案。
对团队来说，这个项目的价值不只是一套博客系统。为了让"没有中心服务器"这件事真正成立，必须重新想清楚数据怎么定位、节点怎么同步、失效之后怎么恢复。这些关于"轻依赖、可独立运行"的思考，后来一直留在团队的架构偏好里。
彭泽辰加入团队
一个能落地的产品，加一个肯啃底层的框架。
2023年6月，iDeal工作室负责人成凯（软件2001班）向指导老师熊老师推荐了一位非计算机专业的同学，表示其对加入工作室感兴趣。熊老师因该同学并非计算机专业学生而有所犹豫，成凯建议先看看该同学已经完成的一些工作和写的代码，再做决定。
次日，该同学向工作室介绍了他开发的静逸教育支援填报辅助系统。该系统已经商业化并长期盈利，证明了他对软件开发的兴趣和能力。同时，他还展示了自己开发的一个开源C语言后端处理Web请求的框架。熊老师在阅读其代码后，发现他在C语言编程技术上有一定的开发潜力和能力，决定同意他加入工作室。这位同学就是Fast-Https的主要创始人彭泽辰。
确定类 Nginx 的产品方向
一套已经跑得起来的请求处理框架，够不够撑起一个 Nginx 式的产品？
2023 年 6 月底，团队围绕彭泽辰此前开源的那套「C 语言 Web 请求处理框架」做了一次完整评估。结论是：它已经具备相当的基础——请求接入、解析与转发的骨架是通的，性能取向也清晰，缺的是产品化所需的配置体系、证书能力与运维体验。换句话说，地基有了，可以往上盖。
基于这一判断，团队把方向明确下来：不再只做一个练手项目，而是沿着这套框架的技术底座继续演进，做成一个类似 Nginx 的开源 Web 服务器产品。这个决定后来直接影响了 7 月的立项——当 SSL 证书过期的问题出现时，团队没有另起炉灶，而是把"让 HTTPS 变得开箱可用"这件事，接到了同一条产品线上。
Fast-Https 正式立项
起因是一次证书过期，落点是一个偏底层的开源项目。
2023 年 7 月初，iDeal 工作室再次遇到一批已开发部署的 Web 应用无法正常访问，排查下来主因仍是 SSL 证书到期。同类故障反复出现，说明靠人记着去续期并不可靠，工作室因此决定开发一款能自动配置 SSL 证书的 HTTPS 代理工具。在熊老师带领下，彭泽辰与张亿贺先做了可行性分析，并用 Go 语言写出了简单原型。
原型跑通之后，讨论的焦点从"修一个故障"转向"要不要立项一个 Web 服务器的开源项目"。熊老师认为，工作室过去主要做企业应用软件与互联网应用开发，但从激发大家的学习兴趣、综合利用所学计算机专业基础知识、培养人才的角度，有必要开立一个偏底层的开源项目；而如果要做 Web 服务器软件，建议尽量采用开发效率更高的 Go 语言。
他同时提出一条硬性要求：这个 Web 服务器首先要能被工作室大量的企业项目真正用起来，而不是停留在演示阶段。项目由他亲自命名为 Fast-Https——fast 意指希望这个服务器足够快，https 意指希望它天生支持 HTTPS 协议及 SSL 认证。至此，Fast-Https 正式立项。
初创团队齐聚
名单定下来，项目才真正开始往前跑。
2023 年 7 月底，Fast-Https 项目迎来新成员：计算 2102 班的豆幸旺与王禹杰加入工作室。加上此前已经加盟的张亿贺、刘浩宇、彭博和成凯，Fast-Https 的初创团队人员就此齐聚。
对一个刚刚立项的项目来说，人往往比代码更紧缺。成员之间技术侧重不同，有人更靠近请求处理与底层实现，有人更熟悉业务场景与部署落地，分工才有可能真正铺开。名单定下来的意义也在这里——此后新增功能模块、补测试、做多平台打包与发布，都有人稳定承接。
按模块分工：config 与 cmd
人到位之后，第一件事是把模块分到人头上。
2023 年 8 月，项目组决定为 Fast-Https 添加 config、cmd 等功能模块，并明确由刚加入的豆幸旺、王禹杰负责完成。config 承接配置的入口，cmd 承载命令行与启动流程，两者是后续所有功能挂载的地基——先把这两块立住，其他模块才有位置可放。
这也是团队第一次以"模块 + 责任人"的方式推进开发：任务边界清楚，接口先行，各自的进度可以并行。对一个刚成立一个月的项目组来说，这种分工方式比写多少行代码更能决定后续节奏。
决定开发 Windows 桌面版
让不写代码的人，也能把服务器跑起来。
2023 年 9 月，项目组决定开发 Windows 平台下的版本，并希望为服务器配一个常驻在 Windows 任务栏的托盘控制程序——启动、停止、查看状态都在托盘里完成。技术方案确定之后，主要安排张亿贺负责开发。
9 月 5 日，为了便于用户对系统进行快速部署、也便于测试验证，项目组详细分析了用户需求，正式确定开发 Windows 平台下的 Fast-Https 桌面应用程序。这一步的意义在于把"给开发者用的工具"改成了"给使用者用的软件"：目标用户不再需要理解配置文件与命令行。
采用 goreleaser 多平台打包
发布不该靠手工重复，打包也得有工程化的做法。
9 月 13 日，在完成详细的需求分析与现有技术调研之后，项目拟采用 goreleaser 对 Fast-Https 进行多平台打包。此前每个平台的产物都需要人工重复一遍构建流程，版本一多就容易出错；交给工具之后，同一份配置就能生成各平台的可执行文件，发布这件事变得可复现。
围绕不同平台的特点，团队同时改进了日志记录、后台运行控制与界面显示：日志要能落盘可查，后台运行要能安静常驻，界面要贴合各平台的使用习惯。这些改动不显眼，却决定了用户第一次打开程序时的感受。
Windows 版本正式发布
9 月 24 日，第一个普通用户也能装上的版本。
9 月 24 日，张亿贺开发完成桌面版本并完成测试，Fast-Https 的 Windows 版本正式发布。从这一天起，使用者不必先装好 Go 环境、也不必对着命令行敲参数——下载、安装、在任务栏托盘里点几下，就能跑起一个支持 HTTPS 的服务。
对一个立项仅两个多月的项目来说，这是一次完整的闭环：需求分析、技术选型、开发、测试、打包、发布，每一环都真实走了一遍。后面所有版本，基本都沿用了这套流程。
safe、cache、auth 三组模块
从"能跑"到"能扛"，中间是这三块能力。
2023 年 10 月，项目组决定为 Fast-Https 添加 safe、cache、auth 等功能模块，分别由豆幸旺、王禹杰、彭博、刘浩宇负责完成。safe 面向安全策略，cache 处理缓存，auth 负责认证——三者都是 Web 服务器绕不开的基础能力，也是把产品从"能跑"推到"能扛"的关键。
模块由不同成员并行推进，接口先定、实现后补。这样的安排让每个人都能完整负责一块功能，而不是在大文件里互相踩脚；也逼着团队把模块边界想清楚，为后面的模块化封装准备了条件。
模块化封装与工作流
为二次开发留出接口，代码才不只是自己的。
10 月 22 日，为便于后续的代码管理与二次开发，项目组着手把代码做模块化封装。团队调研了多种 Go 语言的模块化开发案例，包括 caddy、plugin、pingo 等，比较它们在扩展方式与耦合程度上的取舍，最终确定了项目中模块封装的方案。
在模块化的基础上，团队还借鉴 gin-gonic 处理请求上下文的方式，设置了统一的工作流：一个请求进入后，按既定环节依次流转，各业务模块只需关心自己的那一段。这样既保住了模块之间的边界，也规范了执行过程——新增能力有位置可插，排查问题有路径可循。
进入真实使用场景
第一次不是"演示"，而是真的有人在用。
2023 年 11 月，Fast-Https 开始用于工作室部分系统的开发测试环境。真正的使用和演示完全不同：路径不对、端口被占、证书链异常，各种琐碎问题集中暴露，团队只能一个接一个地修。这些故障后来都变成了产品的一部分。
同一时间，有部分同学开始把产品用在《软件测试》《软件工程课程设计》等课程的大作业练习中。课堂场景对易用性的要求更苛刻——没有人愿意为一个作业读完整套文档，这反过来推动了安装流程与界面提示的改进。
全面测试与 Linux 服务化
有人专门盯质量，版本号才敢往前推。
2023 年 12 月，软件 2101 班的张家悦同学加盟 Fast-Https 团队，主要负责服务器的测试工作。团队由此开始在 Windows 与 Linux 两个平台上对产品进行全面的静态测试、单元测试与性能测试：静态检查守住代码规范，单元测试锁住既有行为，性能测试则回答那个最直接的问题——它到底快不快。
同一阶段还补上了两块能力：在 Linux 系统中，Web 服务器能够以服务的方式启动，做到开机自启、异常退出后自动拉起；以及 Web 服务器安全相关的开发与设计，覆盖响应头、请求限制等基本盘。前者让它能长期驻留在服务器上，后者让它敢暴露在公网里。
Fast-Https 1.0.0 正式发布
1.0 不是功能最多的一版，而是可以被放心依赖的一版。
到这时，Windows 与 Linux 双平台的能力已经成型，各功能模块趋于稳定：配置怎么写、日志怎么看、证书怎么续、服务怎么托管，都有了确定的答案。发布前，团队把这几条主线逐一走通，确认换一台机器、换一个用户，行为依然一致。
1.0.0 的意义在于给出承诺——接口与使用方式短期内不再大改，使用者可以把它当成基础设施来依赖，而不必每隔一段时间重新适配。对一个由学生维护的项目来说，这份稳定比新增功能更难，也更重要。
大创项目定级国家级优秀
中期检查之后，项目被定级为国家级优秀。
2024 年 5 月，Fast-Https 项目参加华北电力大学 2023—2024 学年大学生创新创业训练计划项目立项，在中期检查之后，定级结果为国家级优秀。
对团队而言，这不是一块奖牌那么简单。大创要求写清目标、进度、分工与阶段成果，逼着团队把"我们做了什么"整理成可以被外部检验的材料——而这些材料，后来又被用来申报竞赛、对接社区。
挑战杯北京市三等奖
把技术放进创业语境里，再讲一遍。
2024 年 5 月，Fast-Https 项目参加 2024 年"挑战杯"首都大学生创业计划竞赛，成功从校赛突围，最终荣获北京市三等奖。
创业类竞赛关心的不只是代码写得好不好，而是它解决了谁的问题、市场有多大、凭什么别人做不出来。为了回答这些问题，团队重新梳理了产品的定位与差异点——这套叙事后来也成了对外介绍 Fast-Https 的通用版本。
入驻华为 openEuler 社区
代码走出校园，接受外部开发者的审视。
2024 年 5 月 25 日，Fast-Https 项目通过华为 openEuler 专业委员会审核，正式入驻华为 openEuler 社区。相关记录见《openEuler 社区 2024 年 5 月运作报告》。
入驻意味着项目被放进了国产操作系统生态的坐标系里：代码要经得起外部开发者阅读，提交要遵循社区的协作方式，问题也要回应得更及时。对学生团队来说，这是从"自己做、自己用"到"别人也能用、也会提意见"的转折。
参加中国国际大学生创新大赛
从校赛一路往上，比赛也是产品的压力测试。
2024 年 5 月，Fast-Https 正在参加（原"互联网+"）中国国际大学生创新大赛（2024）。这是国内规模最大的大学生创新创业赛事之一，评审关注技术含量，也关注项目能否持续运行。
备赛过程本身就是一次系统梳理：把两年多的开发历程压缩成几页材料，把"为什么做、做了什么、凭什么继续做"讲清楚。被问住的每一个问题，往往就是产品下一步要补的短板。
参加全国大学生信息安全竞赛
做安全产品的人，先得接受安全的检验。
2024 年 6 月，Fast-Https 正在参加全国大学生信息安全竞赛。与创业类赛事不同，这项比赛更在技术本身：协议细节、证书处理、攻击面收敛，每一处都要经得起追问。
对一个定位为 HTTPS 服务器的项目来说，这类检验尤其对味。团队把比赛中的分析带回了开发过程，重新审视了证书加载、请求校验与默认配置中的安全取舍——这些改动不增加功能，却让产品更值得信任。
持续迭代，仍在进行
比赛划定问题的边界，真实项目暴露真实的 bug。
比赛之外，项目的主线始终是迭代。Fast-Https 继续被用在工作室的企业项目与课程实践中，真实流量带回的反馈比任何测试用例都直接：某个平台的路径差异、某条证书链失效、一次异常退出后的状态残留，都会被逐一修掉，再沉进代码里。
开源社区的协作也成了日常——issue、pull request、版本发布构成稳定节奏。对一个仍在生长的项目来说，版本号会停在某个数字上，迭代不会。