香港电梯数据实测：2.3 万起扶梯事故，设备故障只占 0.39%

国庆长假要来了商场和地铁站的扶梯即将迎来一年里最忙的几天。我顺手把香港机电署公开的电梯扶梯数据扒了一遍——四个 CSV 文件事故、年龄、承建商评级各一份。先说读完的第一观感14 年 23,057 起扶梯通报事故里官方归因给「设备故障」的只有 89 起占 0.39%而全港 73,393 台升降机里31 年以上的老设备占四成。这两个数字放在一起比任何一篇电梯安全的文章都耐人寻味。目录一、机电署的 97 个数据集我抽了四份二、归因口径93% 到 98% 都写着「乘客行为」三、年龄分布四成升降机超过 31 岁四、承建商评级门户说 2025 年更新过数据停在 2018四个要点收尾一、机电署的 97 个数据集我抽了四份机电署在资料一线通上有 97 个数据集升降机、扶梯、游乐设施、气瓶……全部零鉴权。我抽了四份与电梯安全直接相关的扶梯事故记录按主因、升降机年龄分布、扶梯年龄分布、承建商表现评级。每份抓两轮四份字节数与指纹全部一致其中事故表只有 1,439 字节——最小的一份装着 14 年的事故。有一个坑先记下「升降机」lift和「扶梯」escalator在官方数据里是两套设备、两张表。我一开始想算事故率拿着升降机的 73,393 台做分母——错了 6.9 倍。事故表统计的是扶梯扶梯存量在另一张表里10,601 台。分母错表是这份公开数据里最容易踩的坑。二、归因口径93% 到 98% 都写着「乘客行为」importcsvfromcollectionsimportdefaultdictwithopen(原始返回/emsd/reported_escalator_incidents_r0.csv,encodingutf-8-sig)asfh:rows[rforrincsv.reader(fh)ifrandany(x.strip()forxinr)][1:]tot,bydefaultdict(int),defaultdict(dict)forrinrows:tot[r[0]]int(r[2])by[r[0]][r[1]]int(r[2])yearssorted(tot)pb{y:by[y][Passenger Behavior]/tot[y]*100foryinyears}ef{y:by[y][Equipment Fault]foryinyears}print(round(min(pb.values()),1),round(max(pb.values()),1))print(sum(ef.values()),sum(tot.values()),round(sum(ef.values())/sum(tot.values())*100,2))print([yforyinyearsifef[y]0])# 92.5 98.1# 89 23057 0.39# [2014]2011 到 2024 年每年归因给「乘客行为」Passenger Behavior的事故占比在92.5% 到 98.1%之间「设备故障」Equipment Fault14 年加起来 89 起2014 年甚至是一年零起。峰值在 2023 年2,765 起疫情后出行恢复最新 2024 年回落到 1,340 起。怎么解读这个 0.39%数据本身给不出答案它至少有三种可能设备真的可靠法定定期检验在起作用「乘客行为」是个很宽的归因筐——携带超大行李、没扶扶手、在梯上逗留都可能记进去也可能存在通报口径的差异。三种解释我都无法用这份 CSV 证实或证伪所以我只把数字摆在这。能确定的是如果你想在官方通报数据里找「设备故障」的规律这份表的信噪比低到几乎不可能——14 年 89 起年均 6 起。三、年龄分布四成升降机超过 31 岁第二张表是设备年龄。按 18 区 × 8 个年龄段切rows[rforrincsv.reader(open(原始返回/emsd/age_distribution_lift_r0.csv,encodingutf-8-sig))ifrandany(x.strip()forxinr)][1:]totalsum(int(r[3])forrinrows)oldsum(int(r[3])forrinrowsifr[2].startswith((06.,07.,08.)))print(f{total:,},old,round(old/total*100,1))# 73,393 29937 40.8全港73,393 台升降机里31 年以上的有 29,937 台40.8%41 年以上的占 22.0%。分区看更悬殊湾仔 61.3% 的升降机超过 31 岁老城旧楼密集离岛只有 6.2%油尖旺的绝对数量第一6,593 台。扶梯这边总量 10,601 台31 年以上占 27.3%东区最老52.3%。年龄段标签长这样01. 5、06. 31-40——前缀的两位序号是排序的唯一依据。你要是按字符串排序后再切片取「前三个年龄段」靠字典序恰好没错但一旦去掉序号再排序11-15会排在6-10前面。前缀是官方留给你的排序键别嫌它丑。还有一个藏在区间里的问题八段年龄加起来是5到51没有空档也没有重叠可以做总和无损校验——73,393 就是这么加出来的。但反过来任何一份文件都没写这个分布的统计时点这些电梯是哪一天数的文件里没有日期字段门户元数据也只能给出平台采集时间。做「老化趋势」类的时间序列分析时这份表连自己的出生证明都没有只能当横截面用。四、承建商评级门户说 2025 年更新过数据停在 2018第三张表最有意思的不是内容是它的新鲜度。承建商表现评级Performance Rating这份文件的元数据写着的最后修改时间是 2025 年 12 月 30 日——但打开一看期数只有一期10/18也就是 2018 年 10 月。这份数据长这样rows[rforrincsv.reader(open(原始返回/emsd/cpr_rlc_r0.csv,encodingutf-8-sig))ifrandany(x.strip()forxinr)][1:]periodssorted({r[0]forrinrows})safety{}forrinrows:safety[r[3]]r[4]# 承建商编号 - 安全评级fromcollectionsimportCounterprint(periods,len(rows),Counter(safety.values()))# [10/18] 38 Counter({1: 34, 0: 4})期数只有一期10/18——月/两位年份格式也就是2018 年 10 月。38 家注册承建商安全评级只有 0 和 1 两档。这就是我之前在别的数据集里验证过的结论的极端版门户的「更新时间」是平台重新采集的时间戳不是数据内容的时间戳。这份评级表的内容已经 8 年没有更新了而元数据看起来一切正常。做数据管道的人如果拿metadata_modified判断「这份数据还活着吗」会得到一个错误的「活着」。评级内容本身38 家注册承建商安全表现评级只有 0 和 1 两档——1 是正常0 意味着备注列里有警告信或者纪律聆讯定罪记录4 家。Service 质素评级倒是 0–5 五档。还有一个分母陷阱各家被巡查的升降机数量从6 台到 1,142 台差 190 倍——同一张评级榜上巡查 6 台拿了 1 分和巡查 1,142 台拿了 1 分置信度不是一回事。直接按评级排序做「谁最好谁最差」是在拿分母不同的比率排名。那 4 家 0 分的备注列里写着警告信warning letter或纪律聆讯定罪Disciplinary Board conviction——机器可读但想引用它们就得逐条人工核对原文官方没有给结构化的事件编码。四个要点收尾升降机和扶梯是两张表。算事故率之前先确认分母是同一批设备——我拿 73,393 当分母时错得毫无察觉因为两张表长得一模一样归因统计只呈现、不推断。0.39% 的设备故障占比有三种解释CSV 证伪不了任何一种写进结论前先想清楚数据能回答什么门户的更新时间不是数据的新鲜度。评级表元数据 2025 年 12 月、内容 2018 年 10 月——判断数据死活要看内容里的期数不是元数据时间戳年龄段的数字前缀是排序键。01. 5这种丑前缀是官方留给你的去掉它再排序就是另一套顺序。最后照例说明本文只讨论公开数据的口径与工程处理不对任何承建商、任何楼宇的设备状态做评价事故归因的解读留给你。全部数字可复现——四份文件双轮抓取的原始返回与审计脚本13 项断言放在仓库取数时间 2026-09-29。参考链接https://www.emsd.gov.hk/filemanager/en/content_808/dataset/reported_escalator_incidents.csvhttps://www.emsd.gov.hk/filemanager/en/content_808/dataset/age_distribution_lift.csvhttps://data.gov.hk/en-data/api/3/action/package_show?idhk-emsd-emsd1-performance-rating-of-lift-contractors