场馆和赛事，统计的其实是两件事
体育馆本身是一个长期存在的实体：全年都在消耗电、水，无论有没有比赛，机房、安防、公共区域照明都要持续运行。赛事则是一个有明确开始和结束时间的活动，可能借用某座场馆举办，也可能只借用几天时间就撤场离开。如果把这两类数据放进同一个项目统计，赛事当天的能耗峰值会和场馆全年的基础负荷混在一起，既算不清场馆平时的运行水平，也说不清某一场赛事到底带来多少额外的资源消耗，两笔账混在一起，最后谁都说不清楚。
场馆项目记录的是什么
在米兰体育App里创建"场馆项目"，对应的是长期运行的物理空间——总表、分区电表水表、HVAC系统、照明分区，以及日常运营产生的基础负荷。场馆项目按自然月滚动累计，目的是回答"这座场馆平时运行得怎么样"，这部分数据不会因为某一天有没有比赛而重新归零，也不需要为每一场活动单独建一次。场馆项目建立以后通常长期使用，后续的能耗趋势、用水趋势都在同一个项目下持续累积，方便对比不同月份、不同季节的运行差异。
赛事项目记录的是什么
"赛事项目"绑定的是一次活动周期，从布展、比赛日到撤场，还包括预计观众规模、赛事类型等基础信息。因为赛事期间的能耗和人流会明显偏离场馆日常水平，只有单独建立赛事项目，才能算出这场比赛额外增加了多少资源消耗，而不是把峰值直接并入场馆全年数据里拉高整体基线。当赛事涉及大量观众进出时，往赛事项目里补充观众离场和交通数据，也能让这场活动的碳报告边界更完整，不只停留在场馆内部的能耗记录。
两个项目怎么关联又不互相覆盖
米兰体育App允许在赛事项目里选择"所属场馆"，把赛事和承办场馆关联起来，但两边的统计口径依然独立：场馆项目继续按自己的周期累计基础负荷，赛事项目单独核算这次活动期间的增量数据，互不覆盖、互不冲抵。这样设计的好处是，即使同一座场馆一年办多场赛事，每场活动的数据也不会互相稀释，方便对比不同场次的单位观众能耗表现，也方便场馆方向不同举办方分别出具对应的活动报告。
新手建项目时常见的误区
不少用户第一次使用时，习惯把一整年发生的事情都塞进一个项目里，或者反过来，每次举办新赛事都重新建一个场馆项目。建议的做法是：一座物理场馆只建一个场馆项目，长期使用；每次举办新赛事，在这座场馆下新建对应的赛事项目，用完归档即可，不必删除。假设某场馆一个月内举办两场性质不同的赛事（此处为示意场景，非真实数据），分别建立两个赛事项目，才能分别看到各自的能耗特征，而不是把两场活动的数据揉在一起，反而看不清哪场活动效率更高。
