C++26草案未获通过，12票赞成为何不够

掘金热榜文章以“C++26 草案被否，二十八年来头一回”概括此次事件，引起了开发者对标准进程的密切关注。现有资料显示，一次草案表决获得12票赞成，未达到66.66%门槛，因而没有通过；“二十八年来头一回”目前只能视为报道说法，并非已经核实的官方定论。

这不等于C++26被取消。2026年3月28日的WG21委员会批准，与后续以国家弃权票为特征的草案表决，处于不同程序阶段，投票主体和计数口径也不同，不能混算。

表决未通过的环节和范围需要分开判断。单项功能提案被撤回或否决，不等于整个标准版本被否定；某个草案在一次表决中未获得足够支持，也不意味着项目只能终止。按照资料给出的流程，WG21表决之后还要准备最终文档、提交国际审批，标准正式发布则是更后面的环节。

66.66%是比例要求，不是固定票数，因此12票是否足够取决于分母以及弃权票如何计入。报道还称，有12个国家弃权，其中一些是因为无法形成共同立场。如果弃权计入分母，它们会扩大分母却不增加赞成票；如果不计入，影响方式又不同。现有摘录没有给出全部有效票数、反对票数和完整的弃权规则，因此无法独立复算精确差额，更不能据此推算精确票数。

两份材料记录的表决分属不同阶段，票数不能直接比较：

前者是WG21成员表决，后者是以国家代表团为口径的描述，不能把114票与12票作为同一轮表决的票数直接比较，也不能将两者相加。从“国家弃权”的措辞看，后一次表决更接近国际审批层面的国家代表团投票；但在缺少正式投票文件编号、会议名称和程序状态的情况下，不能把这一阶段判断写成确定事实。

程序上仍存在继续推进的空间：WG21批准并不等于最终标准已经发布，后续还要经过文档整理和国际审批；一次未过门槛可以暴露出共识或文本问题，并不自动等于版本被撤销。是否修订、重新送审以及何时再次表决，仍须等待官方安排。

争议最明确的技术议题是合约。合约试图表达函数前置条件、后置条件及断言，以改善接口约束，但包括比雅尼·斯特劳斯特鲁普在内的部分成员反对其复杂性，尤其担心语义会随代码位置发生变化。编译时反射强调无需运行时开销，std::execution则被指出存在文档不完善和完整库支持不足的问题；这些都会影响采用成本，但在没有会议纪要的情况下，不能把任何单项功能认定为草案表决失败的唯一原因。

草案、TS、WG21批准和最终IS所处的状态并不相同。TS是标准化过程中的技术规范，不等于最终国际标准；编译器提前实现某项草案能力，也不代表相关文字已经定稿。cppreference的C++26页面本身仍标注“未完成”，因此工具支持应与标准状态分开判断。

对开发者而言，存量项目没有因这次表决立即修改代码或升级工具链的必要；准备采用C++26的新项目，更稳妥的做法是等待最终文本和稳定工具链；库维护者及试验性团队若要提前试用反射、合约或std::execution，则应固定编译器版本、通过隔离构建开关控制启用范围，并补充兼容性与性能测试，避免把未定稿接口直接暴露给外部用户。

目前仍需官方记录确认四件事：正式分母、弃权票的适用规则、表决未通过的具体程序阶段，以及最终文本与时间表安排。在这些信息补齐前，应优先采用带日期的WG21或ISO官方记录，而不是根据二手标题推断标准命运。表决未通过不意味着流程终止，但采用者应等待文本稳定后再推进，这通常比追逐预览编译器更可控。