# 开发者想说 > 项目作者与核心开发者关于 CheeseWAF 研发初衷、架构执念与安全探索的自述与思考。 --- LLMS index: [llms.txt](/zh/llms.txt) --- > *“安全不应该是昂贵、封闭或让运维疲惫不堪的黑盒，而应该是一套透明、优雅且让人感到踏实的工程基础设施。”* --- ## 写在前面的话 {#preface} 如果你正在阅读这篇文档，或许你正准备在自己的服务器上部署 CheeseWAF，或许你是在排查某个棘手的安全问题，又或许你只是一名对 Web 安全与应用架构感兴趣的同行或爱好者。 无论是哪一种，我都由衷地欢迎你。 这里没有冰冷的命令行参数、也没有晦涩的正则表达式语法，我想用自己简朴的话，和你聊聊为什么会有 CheeseWAF，以及在这个过程中我所坚持与思考的一切。 --- ## 为什么要做 CheeseWAF {#why-cheesewaf} 在确认立项并动手写下 CheeseWAF 的第一行代码前，我和许多网站运维与安全工程师一样，面对日益复杂的网络请求，在高价的商业 WAF 授权报价与传统开源项目的繁杂规则维护、误报漏报率高的困境中难以抉择。 我们常常陷入两个极端： - **过度依赖传统正则特征**：规则越堆越多，不仅维护成本成倍攀升，稍微遇到多层编码或字符嵌套就会被绕过； - **盲目将大模型塞进实时路径**：为了所谓的“智能化”，在同步反向代理链路中强行等待远程 LLM 返回，把一次简单的 HTTP 交互变成几百毫秒甚至数秒的等待，最终拖垮了整个业务系统。 我们坚信，**精准性、低延迟和可维护性是数据平面的生命线，而深度的语义理解应当交给能自己解耦和自我成长学习的异步旁路。** 这便是 CheeseWAF 诞生的起点——我们希望打造一款真正商用级、自包含、开箱即用的自托管 WAF，让每一位开发者和运维团队都能掌握自己的应用安全防护权，不受云端和高价商业授权束缚。 --- ## 我们的设计执念 {#philosophy} 在 CheeseWAF 的演进历程中，有一些工程原则被我们视作底线： 1. **坚持单一二进制与自包含**：把复杂的组件、Web 控制台和安全引擎凝聚在单一可执行文件中，无需先折腾半天数据库、中间件或外部依赖，主项目由 100% Go 语言编写，这使得 CheeseWAF 拥有先天的鲁棒性和极好的可移植性，可以在主流的 Linux、Windows、macOS 平台上直接运行。不仅如此，我们还兼容了龙芯架构（LoongArch），原生支持搭载国产龙芯芯片的设备上正常运行。 2. **请求路径绝不妥协**：最快微秒级处理的请求检测管线源于清晰的抽象语法树（AST）语义解析，根据设备性能参数实时调优的检测管线，经过无数次打磨的 GC 调优和硬件加速，只在追求极致的性能与并发。 3. **把选择权交还给操作者**：从防护等级（Paranoia Level）的逐级推进，到大模型研判结果的自动采纳，你可以在 AI 自动操作和告警人工审批中自主选择，最终防线的掌控和话语权永远在你手中。 --- ## 给使用者的一封信 {#letter-to-community} 做一款严肃的 Web 应用安全产品并不容易，它需要面对瞬息万变的网络攻击手法、复杂的现代 Web 协议演进，以及现实部署环境中的种种严苛挑战。 CheeseWAF 作为一个初来乍到、涉世未深的个人维护开源项目，仍在不断成长中。如果它在某个深夜帮你挡住了一次突如其来的恶意攻击，帮助你的网站初创团队或小公司减轻了商业化 WAF 授权或云上防护的费用，亦或者只是让你的运维工作变得轻松了一点，觉得用起来还算顺手，那便已是我最大的荣幸。 欢迎有任何想法、批评或者建议的用户们通过 [GitHub Issues](https://github.com/LaokeQwQ/CheeseWAF/issues) 或 [邮箱（coqimax@gmail.com）](mailto:coqimax@gmail.com) 与我交流。 最后，由衷感谢您对 CheeseWAF 的认可和信赖，也致敬每一个热爱开源与安全技术的你。
—— CheeseWAF 开发者 & 创始人 老可
2026 年 9 月