实验性功能
WARNING
所有实验性功能均可能 随时 发生破坏性变更或被移除。强烈建议您不要在生产环境中使用这些功能，它们仅用于测试和收集反馈。
为了推动 Task 的快速演进，我们有时会在次要版本中通过实验性标记引入破坏性变更。这使我们在正式发布主版本前能收集到关于破坏性变更的反馈。此流程同样适用于重要非破坏性功能的设计定型前的意见征询。本文档将阐述实验性功能的工作流程及如何参与其中。
您可以通过页面左侧边栏的子菜单查看所有活跃实验性功能的完整列表，点击任一功能可了解详细信息。
启用实验性功能
Task 通过环境变量检测是否启用实验性功能。所有实验功能变量均以 TASK_X_ 前缀开头，后接实验名称。您可在侧边栏中各功能的详情页找到确切的变量名。若将变量设置为 =1 即可启用功能。某些实验可能包含多个提案，此时需将变量值设置为要启用的提案编号（如 =2、=3 等）。
启用实验性功能的环境变量主要有三种设置方式，具体取决于使用场景：
在 task 命令前添加相关环境变量。例如
TASK_X_{功能名}=1 task {我的任务}。适用于临时调用 Task 测试实验性功能。在 "dotfiles" 中（如
.bashrc、.zshrc等）添加环境变量。这将为您的个人环境永久启用实验性功能。shell# ~/.bashrc export TASK_X_功能名=1在根目录 Taskfile 同级创建
.env或.taskrc.yml文件。.env文件应包含相关环境变量，而.taskrc.yml需采用 YAML 格式，将每个实验定义为键值对。此举可在项目层级启用实验性功能。若将此文件提交至版本控制系统，项目其他用户也将默认启用这些实验。
若同时存在这两个文件，
.taskrc.yml中的值具有更高优先级。
experiments:
功能名: 1TASK_X_功能名=1工作流程
实验性功能是我们为主版本发布前进行功能验证的重要手段。由于此机制依赖于社区反馈，我们为此建立了标准化工作流程，确保实验功能得到充分关注与打磨，从而获得最佳实践效果。
以下章节详细说明实验性功能从提案到正式发布的完整生命周期。
1. 提案阶段
所有实验性功能始于 GitHub issue 形式的提案。若维护者认定某议题获得足够支持，且属于破坏性变更或需要用户反馈的复杂/争议性功能，便会为其添加 status: proposal 标签。此时议题进入提案阶段并开启咨询期，期间鼓励用户就该提案对 Task 使用的影响提供反馈。咨询期时长由维护者酌情决定。
2. 草案阶段
提案咨询期结束后，贡献者可开始初步实现。当 PR 提交后，维护者将确保其符合实验性功能要求（如标志格式正确等）并合并功能代码。该功能发布后，状态将更新为 status: draft 标签，表明实验性实现已可用并开放反馈。
INFO
草案阶段可能根据用户反馈对实现进行重大调整。实验性功能 不提供稳定性保证，且可能 随时 被废弃。
3. 候选阶段
当社区达成可接受的共识且反馈/变更频率显著降低后，状态将更新为 status: candidate 标签。这表明提案 极有可能 被采纳，并进入最终意见征询与微调阶段。
4. 稳定阶段
当实验性功能经历充分验证且无重大变更后，将获得 status: stable 标签。此时该功能将与 Task 其他功能享受同等待遇，所有变更 必须 保持向后兼容。这使得用户能无痛迁移至新功能，无需担心未来版本发生破坏性变更，为主版本升级提供最佳体验。
5. 发布阶段
当 Task 发布新主版本时，所有标记为 status: stable 的实验将转为 status: released 状态，其行为将成为 Task 的默认行为。处于早期阶段（即非稳定状态）的实验将无法发布，继续在新版本中保持实验状态。
废弃/替代
若实验在任何阶段未能达到预期，将根据具体情况标记为 status: abandoned 或 status: superseded 状态，这些实验最终将从 Task 中移除。