后端Web框架【免费下载链接】CodeIgniter4Open Source PHP Framework (originally from EllisLab)项目地址https://gitcode.com/gh_mirrors/co/CodeIgniter4点击查看免费下载CodeIgniter 4 是一个成熟的 PHP 开源全栈框架其生产代码位于system/测试代码在tests/system/中与之一一镜像。仓库根目录下的 AGENTS.md 是一份面向框架贡献者尤其是 AI 协作场景的硬性开发准则系统性地定义了改代码前的必读材料、按目标分支划分的兼容性红线、编码规范、FrankenPHP Worker Mode 下的长驻进程约束、测试与文档要求。读完本文你将掌握如何在 CodeIgniter 4 仓库中安全地提交改动、如何理解develop与4.*分支的兼容性差异、如何遵循 strict_types 与属性类型约定以及如何为 Worker Mode 编写不会造成状态泄漏的代码并学会用最小化的聚焦验证替代完整 CI 矩阵。改动之前必须查阅的四份文档AGENTS.md 明确规定在对仓库做任何改动之前应当先查阅以下文件contributing/pull_request.mdPR 提交流程与审查要求contributing/internals.md框架内部工作机制contributing/styleguide.md代码风格指南tests/README.md测试环境搭建与运行说明其核心理念是跟随既有代码与测试在引入新的抽象或约定之前先在受影响组件中搜索是否已有现成实现避免重复造轮子。这保证了框架长期保持最小有效抽象、组件尽量独立的演进风格。目标分支与兼容性策略developvs4.*AGENTS.md 强调兼容性永远以 PR 的目标基分支为评判基准而不是贡献者自己的源分支或特性分支。当基分支未知时一律按更严格的develop策略执行。Base branchdevelop下一个补丁版本线禁止有意的不兼容变更develop对应下一个 patch-release补丁版本线因此必须严格保持向后兼容具体包括保留公共与受保护的 API、文档化行为、配置默认值、生成的项目文件、异常以及可观察的副作用不得删除已弃用deprecated条目不得修改公共/受保护方法签名、可见性以及接口/抽象类的继承要求Bug 或安全修复可以纠正错误行为但必须保留文档化契约与常规合法用法若某个修复必然破坏兼容性则应改投到合适的 minor 分支而不是develop。Base branch4.*minor 版本线允许小而有意的兼容性破坏Minor 版本线如4.9允许接受小的、刻意的兼容性破坏前提是它能实质性改进框架或完成文档化的弃用生命周期每个破坏必须范围收窄、明确且有正当理由绝不能是重构的偶然副作用弃用 API 最早只能在第二个后续 minor 版本中移除例如在 4.6.x 弃用的 API最早到 4.8.0 才能移除且必须提供受支持的替代方案每个被接受的破坏都需要新行为的测试、minor 版本 changelog 条目、upgrading guide 中的迁移说明。所有基分支通用的硬性约束生产代码必须能在PHP 8.2上运行即使本地安装了更新的 PHP 版本也不得要求更高版本这一要求与 composer.json 中的php: ^8.2约束一致方法签名、属性、常量、默认值、异常、副作用、配置和生成的项目文件都属于兼容性敏感范畴大规模重构与生态级迁移需求属于 major 版本的工作而不是 patch 或 minor 版本依赖必须可注入当框架服务作为默认值时要保留应用替换它的能力除非任务明确需要否则不要新增或更新 Composer 依赖不得修改system/ThirdParty/目录下的代码——这是第三方代码如 Escaper、Kint、PSR 实现的保留区在 composer.json 的 autoload 配置中也明确将其排除在 classmap 之外。编码规范strict_types、原生类型声明与静态分析纪律AGENTS.md 对编码风格提出了三条可操作、可审查的硬性要求。strict_types跟随就近代码勿机械添加不要机械地给每个文件添加declare(strict_types1)。正确做法是查看附近代码并检查 rector.php 中DeclareStrictTypesRector的排除列表——PHP 文件默认使用严格类型除非在rector.php中被排除。现有排除项如app/目录、system/CodeIgniter.php、system/Config/BaseConfig.php、system/View/Parser.php等必须视为有意的兼容性约束不得在没有专门理由和测试的情况下移除。属性类型新属性必须原生类型声明旧属性不得机械改动每个新类属性必须有原生类型声明并使用 PHP 8.2 支持的最精确类型只有属性有意接受不相关类型时才允许使用mixed不得机械地给现有公共/受保护属性添加或修改类型——属性类型会影响继承必须遵循目标分支的兼容性策略。PHPDoc 与静态分析仅在原生类型无法表达的额外信息时才添加 PHPDoc不要重复父类或接口已有的 docblock绝不允许通过压制静态分析错误或更新 baseline 来让检查通过——仓库维护了 phpstan-baseline 目录与 psalm-baseline.xml这些是已知问题的记录而非掩盖问题的工具。FrankenPHP Worker Mode长驻进程下的状态管理核心章节AGENTS.md 用最大的篇幅描述了 Worker Mode——这是仓库当前最值得关注的技术主题。在传统 PHP 模型中每个请求都由独立进程处理框架每次完整启动而在 FrankenPHP Worker Mode 中一个进程常驻并服务多个请求框架只启动一次随后在一个进程内循环处理多个请求。入口模板与安装命令Worker Mode 的入口点源码模板位于 system/Commands/Worker/Views/frankenphp-worker.php.tpl由worker:install命令发布为public/frankenphp-worker.php。该命令的实现见 system/Commands/Worker/WorkerInstall.php它实际发布两个文件frankenphp-worker.php.tpl→public/frankenphp-worker.php入口点Caddyfile.tpl→CaddyfileFrankenPHP/Caddy 服务器配置执行方式为php spark worker:install当发布版本的模板发生了既有安装必须更新的变更时升级指南会要求用户用php spark worker:install --force重新发布。模板是唯一事实来源切勿直接编辑已生成的public/frankenphp-worker.php。启动与请求处理的生命周期从 frankenphp-worker.php.tpl 可以看到完整流程版本检查要求 PHP 8.2否则返回 503一次性启动定义FCPATH、切换到 public 目录、加载app/Config/Paths.php然后调用Boot::bootWorker($paths)见 system/Boot.php完成一次性的环境加载、autoloader 注册、异常处理器初始化与CodeIgniter实例创建请求处理器每个请求依次执行——DatabaseConfig::reconnectForWorkerMode()重连数据库实现见 system/Database/Config.phpServices::reconnectCacheForWorkerMode()若缓存实例已存在且ping()失败则重连实现见 system/Config/BaseService.php$app-resetForWorkerMode()清空请求级状态——request、response、router、controller、method、output与计时信息实现见 system/CodeIgniter.php通过service(superglobals)用新鲜的$_SERVER/$_GET/$_POST/$_COOKIE/$_FILES/$_REQUEST刷新超全局快照$app-run()执行应用若配置开启forceGarbageCollection则执行gc_collect_cycles()防止内存泄漏请求后清理frankenphp_handle_request($handler)循环返回后关闭 session、回滚未提交事务、重置 Factories、按配置重置服务与事件监听器。请求后清理的关键调用链循环尾部依次执行Services::session()-close()关闭会话DatabaseConfig::cleanupForWorkerMode()检测到未提交事务transDepth 0时记录错误日志并逐层transRollback()随后resetTransStatus()复位事务状态见 system/Database/Config.phpFactories::reset()重置工厂缓存Services::resetForWorkerMode($workerConfig)重置除持久化服务外的所有服务实例见 system/Config/BaseService.php 起Events::cleanupForWorkerMode($workerConfig-resetEventListeners)在 CI_DEBUG 下清空性能日志并移除DBQuery监听器见 system/Events/Events.php 起调试模式下Services::toolbar()-reset()复位调试工具栏状态。WorkerMode 配置项相关配置位于 app/Config/WorkerMode.php包含三个属性配置属性类型默认值作用persistentServicesliststringautoloader、locator、exceptions、commands、codeigniter、superglobals、routes、cache这些服务在请求之间不被重置不在列表中的服务每请求重置防止状态泄漏resetEventListenersliststring[]空列表指定在请求之间需要移除监听器的事件名。若在事件回调内部而非Config/Events.php顶层注册监听器Worker Mode 下会跨请求累积需要在此登记forceGarbageCollectionbooltrue是否在每请求后强制执行垃圾回收防止内存泄漏代价是少量性能开销给改动者的 Worker Mode 检查清单AGENTS.md 要求只要改动涉及应用启动、请求处理、响应发送、关闭、超全局变量、会话、数据库或缓存连接、服务、工厂、事件、工具栏状态、静态状态或其他请求生命周期行为即使该改动不包含 worker 入口模板本身也必须审查该入口模板。具体要对比传统每进程一请求与 worker一进程多请求的差异并将可变状态分类为进程生命周期状态process-lifetime随进程常驻有意持久化状态intentionally persistent如persistentServices列表中的服务请求级状态request-specific必须在每请求刷新或重置绝不允许泄漏到下一个请求。同时必须保持每请求重连 → 框架重置 → 超全局刷新 → 应用执行 → 请求后清理这一顺序不被破坏。此外system/Boot.php 中的checkOptimizationsForWorker()会强制要求Config\Optimize的configCacheEnabled与locatorCacheEnabled在 Worker Mode 下必须关闭否则启动直接报错退出——这是缓存/定位器优化与常驻进程冲突时的一个典型兼容性约束。测试要求回归优先、聚焦验证AGENTS.md 对测试提出了明确且严格的要求每个 Bug 修复都应附带一个回归测试且该测试在修复前必须失败测试失败路径、异常、边界条件和状态清理而不仅是 happy path优先使用项目风格指南中描述的严格、专用 PHPUnit 断言除非文档化行为或规格发生了变化否则不得削弱或删除现有测试。聚焦验证Focused Validation而非本地全量 CIGitHub Actions 才是全量验证的权威来源不要在本地复刻完整 CI 矩阵。正确的做法是只运行覆盖本次改动的最窄 PHPUnit 测试文件或组件例如vendor/bin/phpunit tests/system/Component/ClassTest.php仅当文件级静态分析或格式检查快速且直接相关时才运行默认不要运行完整 PHPUnit 套件、composer phpstan:check、composer cs、Psalm、Structarmed 或仓库级 Rector 分析在提交信息/PR 描述中明确报告执行了哪些聚焦检查、哪些验证留给了 CI。配套的测试运行说明见 tests/README.md测试默认使用 SQLite3 瞬态内存数据库可通过app/Config/Database.php、phpunit.xml或.env中的database.tests.*键切换整个套件用./phpunit运行Windows 用vendor\bin\phpunit可用--exclude-group DatabaseLive跳过需要真实数据库的测试PHPUnit 分组Group约定包括AutoReview、CacheLive、DatabaseLive、SeparateProcess与Others。文档同步要求涉及公共 API、行为、消息或默认值变更的改动可能需要同步更新用户指南user_guide_src/source/和 changelogchangelogs/。需要用户操作包括配置变更的改动还可能需要添加 upgrading-guide 条目对于4.*目标分支每个有意的兼容性破坏都必须在 minor 版本 changelog 及其 upgrading guide 中双重记录。结语AGENTS.md 是 CodeIgniter 4 仓库如何被可持续地改进的元规范它把兼容性红线、编码纪律、Worker Mode 状态管理和聚焦验证浓缩成了一套可执行清单。对贡献者而言最值得记住的三件事是以目标基分支判断兼容性、任何请求生命周期改动都要对照 worker 入口模板做状态分类、本地只跑最窄的聚焦验证而把全量矩阵交给 CI。这套规范不仅适用于人工 PR也天然适合 AI Agent 在仓库中自主完成安全、可审查的改动。赞分享后端Web框架【免费下载链接】CodeIgniter4Open Source PHP Framework (originally from EllisLab)项目地址https://gitcode.com/gh_mirrors/co/CodeIgniter4点击查看免费下载相关推荐Vuetify 4 仓库开发指南分支策略、命令工作流与 AI 协作编码规范Vuetify 4 仓库开发指南分支策略、命令工作流与 AI 协作编码规范 本文基于 Vuetify 仓库根目录的 CLAUDE.md 其内容为指向 AGE前端UI组件CodeIgniter 4.7.0 发布详解FrankenPHP Worker Mode、PHP 8.2 基线与破坏性变更升级指南CodeIgniter 4.7.0 发布详解FrankenPHP Worker Mode、PHP 8.2 基线与破坏性变更升级指南 CodeIgniter 4后端Web框架Lean 4 标准库代码风格指南从空白规则到策略证明的完整规范Lean 4 标准库代码风格指南从空白规则到策略证明的完整规范 导读 Lean 编译器并不会强制检查代码的排版格式但标准库是多人长期协作、持续演进的大型代码编程语言编译器形式化验证语言运行时标准库上一篇Jasper语音计算平台10分钟快速搭建你的个人语音助手下一篇Bucardo 终极指南高性能 PostgreSQL 多主复制解决方案创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考