工商业分时电价API不是返回一个简单价格而是返回一组可被系统理解的电价数据结构。一个合格的分时电价API至少要表达省份、城市、电压等级、月份、峰平谷尖时段、代理购电价构成、更新时间和数据状态。很多能源系统一开始处理电价数据时会把电价理解成一个简单数字。但工商业分时电价并不是单个价格而是一组和地区、月份、电压等级、用户类型、时段、价格构成相关的结构化数据。如果字段设计过于简单后续会遇到几个问题只能表达峰平谷表达不了尖峰、深谷、季节性时段。只能表达电度电价表达不了容量/需量、代理购电价构成。只能表达当前月份表达不了历史回测。只能按省份查无法处理城市、园区、电压等级差异。只能人工展示无法稳定接入EMS、储能测算、CPO系统。因此电价API字段设计的核心不是把表格搬到接口里而是把电价业务规则建模成系统可理解的数据结构。建模的四层结构建议采用四层结构层级作用示例地理层确定适用区域province/city/region用户层确定适用用户和电压等级voltageLevel/userType时间层确定适用月份和日内时段month/startTime/endTime价格层确定价格类型和价格值priceType/periodType/price示例字段示例字段{ province: 广东, city: 广州, voltageLevel: 10kV, userType: industrial_commercial, month: 2026-07, priceType: tou_price, periods: [ { periodType: sharp_peak, label: 尖峰, startTime: 10:00, endTime: 12:00, price: 1.3568, unit: CNY/kWh } ] }periodType不要写死成三类很多系统会把分时电价写成{ peak: 1.02, flat: 0.68, valley: 0.31 }这个结构简单但扩展性差。推荐把时段做成数组并用periodType标记类型{ periods: [ { periodType: peak, startTime: 08:00, endTime: 11:00, price: 1.02 }, { periodType: sharp_peak, startTime: 19:00, endTime: 21:00, price: 1.35 }, { periodType: deep_valley, startTime: 01:00, endTime: 05:00, price: 0.22 } ] }这样可以兼容不同省份的规则也方便后续增加节假日、季节性或气温影响电价。价格构成字段建议如果系统不仅要做用电成本还要做成本拆解建议增加价格构成{ priceComponents: { energyPrice: 0.5123, transmissionDistributionPrice: 0.2241, governmentFund: 0.0268, marketAdjustment: 0.0712 }, totalPrice: 0.8344 }字段命名要避免过度中文化。内部展示可以用中文标签但API字段建议使用稳定英文命名减少前后端和第三方系统接入成本。错误码设计电价API不只是返回数据还要告诉调用方为什么没有数据错误码含义建议处理PRICE_NOT_FOUND未找到对应电价检查省份、月份、电压等级PROVINCE_NOT_SUPPORTED暂不支持该省份引导申请覆盖范围MONTH_NOT_RELEASED对应月份尚未发布查看更新日志INVALID_VOLTAGE_LEVEL电压等级参数错误使用字段字典中的枚举值RATE_LIMITED调用频率超限稍后重试或升级套餐常见问题Q分时电价API最重要的字段是什么A最重要的是省份、城市、电压等级、月份、时段类型、开始时间、结束时间、价格、单位、更新时间和数据状态。对工商业场景还要考虑代理购电价构成、容量/需量口径和特殊规则说明。Q为什么不建议把峰平谷写成固定字段A不同省份可能存在尖峰、深谷、季节性时段和节假日规则。如果把字段写死成peak、flat、valley后续扩展现货电价、特殊电价和多省规则时会很困难。Q分时电价API和现货电价API的字段区别是什么A分时电价API更关注月度、峰谷时段和工商业电价构成现货电价API更关注日期、时间粒度、96点序列、日前/实时口径、节点或统一结算点等字段。
`)
