一个票种在一年里可能有四五套价格：旺季平日、旺季周末、淡季、夜场、节假日临时加价。看着只是给同一张票改数字，配错了就会出现游客在小程序看到的价和窗口打的价不一致，最后只能按贵的那个赔。顺序比功能重要。

第一步是日历，不是价格表

先把一年分成若干种“日型”：旺季日、平日、淡季日、特殊日。日型是日历属性，挂在日期上，不挂在票种上。这一步做扎实，后面所有价格都是“某票种在某日型多少钱”，改价只需要维护日历和一张二维表。反过来，如果一开始就用“某个日期区间单独设价”的写法，两三个月之后会攒出一堆重叠区间，谁覆盖谁没人说得清，改一处要检查十几处。特殊日要留手工指定的入口：本地节庆、临时活动、天气原因闭园半天，这些都落在特殊日型里，而不是临时插一个区间。

/d/file/news/hyzx/2022/06-08/a76fbdc25ca83b091d07d0c78132eadd.png

夜场建议做成独立票种

夜场和日场往往不是同一个产品：包含的项目不同、可进的区域不同、有效时段是硬约束。如果只在同一票种下加一个时段价，很容易出现夜场票在下午被核销的情况，检票端没有判断依据。做成独立票种之后，票种自带可售时段和可售区域，价格、库存、报表三条线都干净。只有那种“同一张票、只是下午五点后入园便宜些”的场景，才用时段价，且要在核销时校验首次入园时间。

价格表的优先级要能看见

后台要能一眼看到最终生效价是怎么来的：基础价、日型价、时段价、人群优惠、渠道价、活动减免，六层里哪几层命中了。我们的做法是每一层都要写明适用范围与生效时间，并且提供一份试算工具——输入日期、时段、人群、渠道，输出最终价格和逐项来源。没有这个试算入口，改价就变成开盲盒，只能等游客投诉才知道配错了。

/d/file/news/hyzx/2026/06-26/ead4d0cd37a02fcf897aad33f96f5dfe.jpg

还有一条常被忽略：调价要在系统里设定开始展示的时间，而不是点保存就立刻覆盖页面。上午挂出、下午生效，中间这段时间窗口和客服的口径要一致，否则游客会拿着旧价格的截图来争执，而现场没有任何依据能解释这张截图是从哪来的。

优惠叠加：三种模式选一种，别混用

折上折最容易失控，两个各自合理的优惠叠起来可能低于成本；取最优是常见做法，同一订单里同类优惠只生效一个；互斥是某些特定减免不允许与其他活动同用。系统里要支持按优惠类别配置叠加关系，同类的互相排斥、跨类的按优先级累加，并且设置一个最低成交价的兜底参数。这个兜底值不必对外公布，但它是最后一道防线，避免叠加算出零元甚至负数。

改价对已售票的影响，写在票面上就是快照

下单那一刻的价格、命中的规则、有效期都要固化成快照。之后改价只影响新售的票，退票按购买时实付退，不按新价退——这一条如果被系统按当前价格算退款，会造成不该有的差额纠纷。跨期改价还要注意有效期口径：旺季票淡季还能不能用，是看购买时的规则还是使用时的规则，两种都可行，但只能选一种并写进票面说明。

落地顺序建议是：先定日型日历，再配基础价与日型价，然后上时段与夜场，最后才是人群和渠道优惠。前两步跑顺再叠后几步，一次上六层的话，出问题时没人能判断是哪一层覆盖错了。