营业时间与联系模块：营业时间、例外情况及联系方式

营业时间与联系模块在到访或联系失败之前回答一个实际问题：**我何时可以联系到这家特定的商家，应该使用哪种方式？**它将每周时间表、带日期的例外情况、电话和邮件整合为一个可见且机器可读的单元。

为什么此元素很重要

营业时间和联系方式与实际的承诺紧密相关。读者可能正在决定是否前往、在短暂的休息时间打电话、安排紧急维修或咨询无障碍需求。含糊的营业时间会将不确定性成本转嫁给该用户。一个完整的模块应标明分店名称、时区、常规时间表、相关例外情况以及适合该任务的联系方式。

其心理机制关乎信心与补救。「正在营业」只有在同时显示打烊时间时才有帮助。电话号码只有在能够联系到正确的团队或说明不同的接听时间时才有帮助。带日期的例外情况让读者确信他们关心的日期已被考虑；替代联系方式则防止走入死胡同。

搜索引擎、地图产品、语音助手、AI 智能体以及目录信息源必须将每个时间和联系途径连接到正确的地点。页脚放一个号码、地图卡片放另一个号码、JSON-LD 使用过时的营业时间——这会产生多个看似合理的答案。类型化字段能够保留地点、日期、时间、时区、例外情况、联系目的和验证时间之间的关系。

可见模块仍然是面向读者的事实来源。结构化数据不得引入更长的营业时间、另一个电话号码或隐藏的例外情况。尽可能从同一个运营记录中生成两种输出。

何时使用

在营业时间或直接联系方式决定用户能否完成预期操作的地方使用此元素。它适用于有员工值守的商店、诊所、办公室、餐厅、服务点、景点和分店。也适用于具有独立咨询途径或运营窗口的服务页面，以及包含运营联系信息的公司或分店简介。

每个独立运营的地点使用一个模块。即使时间表相同，也需要独立的身份，因为例外情况、时区和电话路由可能会不同。目录页面可以显示紧凑模块，但每个时间表必须归属于一个地点。

常见近似情况需要使用不同的模型：

• 预约日历描述的是可用的预约时段，而非商家通常营业的时间。商家可能在营业，但没有剩余预约。
• 客户支持时间不一定与分店营业时间相同。应将其标注为支持可用时间，并与该联系途径关联。
• 产品可用性说明的是商品是否能获取到。「正在营业」并不能证明所选商品有库存。
• 配送时间窗口说明的是订单可能送达的时间，而非客户可以致电仓库的时间。
• 一次性活动时间表属于活动本身。不要为了表示它而覆盖永久地点的营业时间。
• 无人值守的服务区、邮箱、注册地址或虚拟地点不得呈现为读者可以到访的场所。

元素编写规则 具有优先权：选择此元素是因为该段落的目的是说明运营时间和联系途径，而不是因为当前的设计恰好类似于卡片、表格或页脚。

放置位置

在地点或分店页面上，将完整模块放置在地点身份和地址之后、路线指引、停车、预约或到访规划详情之前。读者不应在了解该地点是否营业之前先看到评论或推广内容。紧凑的顶部状态区域应链接到完整的时间表，并源自同一数据。

在服务页面上，仅当该联系途径和营业时间适用于该服务时，将模块放置在咨询操作旁边。对于多个地点，需要先选择地点再显示时间表。页脚可以重复品牌联系途径，但不能替代页面特定的模块。

该模块可以与同一地点的地址、地图、路线指引或预约操作放在一起。但不能与冲突的状态、另一个分店的号码、看似共享其营业时间的日历或不相关的过期信息放在一起。将「仅限紧急电话」等限定词保留在其对应的联系途径旁。

在移动端，保持顺序：地点名称、当前状态及打烊时间、每周时间表、带日期的例外情况、标注任务的联系途径，然后才是操作按钮。粘性电话或路线操作必须使用相同的地点记录，且不得隐藏联系途径的限制。

构成要素

1. **地点身份：**标明分店或服务点名称，并携带稳定的内部标识符。
2. **当前状态：**显示「营业中」「休息中」「24 小时营业」或「需预约」，并在可可靠计算时附加下一个重要变化。
3. **常规每周时间表：**记录每一天（包括明确标注休息的日期），使用当地时间。
4. **时区：**标识用于解读时间表和夏令时变化的 IANA 时区。
5. **例外情况：**以绝对日期形式给出休息、缩短营业、延长营业或季节性时段。
6. **联系途径：**提供标准化的电话号码和邮箱地址，并附有人性化标签。
7. **用途与可用性：**说明每条途径处理的任务，以及当该途径的监控时间与营业时间不同时的监控时段。
8. **操作按钮：**提供可访问的「拨打电话」「发送邮件」「预约」或「路线指引」操作，且不替换可见的值。
9. **验证信息：**记录运营数据源最后确认详情的时间。

设计示例

每个变体都需要地点名称、仅使用颜色的文本状态以及相同的数据契约。

**完整每周时间表。**地点页面的默认方案显示所有七天，仅在相邻日期时间相同且分组保持可扫描性时合并。

**紧凑的当天摘要。**在顶部区域、目录行或移动面板中，包含当前状态、下一个时间变化、最近的例外情况以及显示完整一周的控件。

**节假日及一次性例外情况。**在相关期间内，将带日期的覆盖时间列在常规时间表旁边。使用「休息」而非显示空的时间范围。

**季节性营业时间。**标注季节名称及其开始和结束日期。显示下一个时间表何时生效，而非悄无声息地替换表格。

**多条联系途径。**标注每条预订、服务、无障碍或紧急途径的用途；避免使用无说明的号码。

**需预约或分时段服务。**将前台时间、预约可用性和紧急联系方式分开，因为它们代表不同的承诺。

参数

「来源」描述组件获取该字段的位置，而非拥有该事实的运营系统。

使用 variant=full、compact 或 contact-first。跨夜时段（如 22:00–02:00）从指定日期开始，于下一个日历日结束。同一天内的多个时段为独立的常规营业时间项，这样可以保留午间休息，而无需虚构一个连续的营业时段。

语法和代码示例

三种形式都编码相同的地点、时区、时间表、例外情况和标注途径。发布平台需在生产使用前注册适配器。

可移植 Markdown 指令

:::hours-contact{location-id="riverside-repair" timezone="America/New_York" verified="2026-08-27" variant=full}
## Riverside Repair — 营业时间与联系方式

::item{type=hours days="Monday-Friday" status=open opens="09:00" closes="17:30"}
常规维修车间和前台时间。
::
::item{type=hours days=Saturday status=open opens="09:00" closes="13:00"}
::
::item{type=hours days=Sunday status=closed}
::
::item{type=exception date="2026-12-25" status=closed}
圣诞节休息。
::
::item{type=phone value="+12125550146" purpose="Repairs and bookings"}
电话在常规营业时间内接听。
::
::item{type=email value="service@example.com" purpose="Service enquiries"}
回复在常规营业时间内处理。
::
:::

Hugo 短代码

{{< hours_contact location_id="riverside-repair" timezone="America/New_York" verified="2026-08-27" variant="full" >}}
  {{< hours_item type="hours" days="Monday-Friday" status="open" opens="09:00" closes="17:30" >}}常规维修车间和前台时间。{{< /hours_item >}}
  {{< hours_item type="hours" days="Saturday" status="open" opens="09:00" closes="13:00" >}}{{< /hours_item >}}
  {{< hours_item type="hours" days="Sunday" status="closed" >}}{{< /hours_item >}}
  {{< hours_item type="exception" date="2026-12-25" status="closed" >}}圣诞节休息。{{< /hours_item >}}
  {{< contact_item type="phone" value="+12125550146" purpose="Repairs and bookings" >}}电话在常规营业时间内接听。{{< /contact_item >}}
  {{< contact_item type="email" value="service@example.com" purpose="Service enquiries" >}}回复在常规营业时间内处理。{{< /contact_item >}}
{{< /hours_contact >}}

每个参数都是命名参数；位置参数和命名短代码参数绝不混用。

WordPress

<!-- wp:amicited/hours-contact {"locationId":"riverside-repair","timezone":"America/New_York","verified":"2026-08-27","variant":"full"} -->
<!-- wp:amicited/hours-item {"days":["Monday","Tuesday","Wednesday","Thursday","Friday"],"status":"open","opens":"09:00","closes":"17:30"} /-->
<!-- wp:amicited/hours-item {"days":["Saturday"],"status":"open","opens":"09:00","closes":"13:00"} /-->
<!-- wp:amicited/hours-item {"days":["Sunday"],"status":"closed"} /-->
<!-- wp:amicited/hours-exception {"date":"2026-12-25","status":"closed","label":"圣诞节休息"} /-->
<!-- wp:amicited/contact-route {"type":"phone","value":"+12125550146","purpose":"Repairs and bookings","note":"电话在常规营业时间内接听。"} /-->
<!-- wp:amicited/contact-route {"type":"email","value":"service@example.com","purpose":"Service enquiries","note":"回复在常规营业时间内处理。"} /-->
<!-- /wp:amicited/hours-contact -->

原生 WordPress 区块应将时间表和联系途径保存为类型化的子记录，而非一个富文本字段。可见模块和 JSON-LD 应从这些记录中读取数据。

好与坏的示例

好的示例

**Riverside Repair — 周四营业时间：**09:00–17:30 营业。周六 09:00–13:00；周日休息。2026年12月25日休息。维修与预订请在营业时间内致电 +1 212 555 0146，或发送邮件至 service@example.com 。时间为 America/New_York 当地时间。最后验证：2026年8月27日。

该示例之所以有效，是因为分店名称、日期解读、时间表、例外情况、联系途径用途、可用性和时效性都明确列出。读者可以据此行动，机器则保留每个关系。

坏的示例

我们营业到很晚！ 致电我们：555-0146。节假日营业时间可能有变。随时给团队留言。

该示例之所以失败，是因为「很晚」不是一个时间点，号码缺少国家代码和用途，没有标明地点或时区，且节假日提示未给出具体日期。「随时」做出了一个不明确的承诺；结构化数据将不得不进行猜测。

Schema 标记与无障碍

对于真正的实体商家，该模块可以提供最具体的适用 LocalBusiness 子类型。常规时段映射到 openingHoursSpecification，包含 dayOfWeek、opens 和 closes；带日期或季节性覆盖映射到 specialOpeningHoursSpecification，根据范围需要使用 validFrom 和 validThrough。可见地点和结构化实体应共享一个稳定的 @id，这样营业时间就不会被关联到不同的分店。

电话号码和邮箱可以作为主要公共途径填充到商家实体中。特定用途的联系途径可以使用 contactType、telephone 或 email、areaServed、availableLanguage 和 hoursAvailable（当已知且可见时）填充 contactPoint。排除内部部门、个人分机、追踪号码和无人监控的邮箱。

例外情况仅在其有效日期内覆盖常规时间表。休息需要明确的内容状态和遵循所选消费者文档化表示的适配器映射。空字符串或省略的日期看起来像数据缺失。需测试跨夜时段、分班制、季节性时间表和夏令时转换。

Schema 是一种映射输出，而非独立的数据源。模块、JSON-LD、地图信息、商家简介和操作链接必须保持一致。如果同步失败，则抑制像「正在营业」这样不确定的衍生状态，并显示有最后验证时间的时间表。

无障碍从语义化文本开始。使用标题、列表或描述列表来呈现联系途径，仅当日与时间的关系受益于表格时才使用表格。设置表格标题的作用范围，在文本中标注当天，使例外情况无需悬停即可查看，并暴露可通过键盘操作的展开状态。

电话链接使用标准化的 tel: 值并附带可读的显示号码；邮箱链接使用有效的 mailto: 地址。无障碍名称应描述操作，例如「致电 Riverside Repair 预订」。切勿自动触发拨打电话或发送邮件、抢夺焦点或重复播报状态更新。

编写规则

以地点名称和当前状态开头。显示实时状态时，添加下一次变化：「营业中 — 17:30 打烊」是可操作的；仅显示「正在营业」是不完整的。使用当地时间，并在读者、员工或地点跨越时区时说明时区。

在完整变体中显示所有七天。仅当每个时段都匹配时才合并连续日期。使用「休息」「24 小时营业」或「需预约」而非留空。显示分班制的两个时段以及跨夜时段的起始日期。

以绝对日期形式发布例外情况，并始终说明其影响。在影响读者之前展示它们；在审核日志中保留后删除过期条目。季节性时间表需要开始和结束日期。

完整模块保持一行当前状态、七行或更少的每日分组行、零到六个相关即将发生的例外情况以及一到四条联系途径。每个途径标签应为一到四个词；每个限定说明不超过 40 个词。使用冷静的运营语言而非营销文案。

切勿包含模糊的「营业时间可能有变」而不列出实际已知的例外情况、促销声明、无关价格、员工简介、产品库存、预约库存或没有用途和回复预期的通用联系表单。切勿未经明确的运营批准发布个人手机号码或员工邮箱。不要说某途径 24/7 有人监控，除非人员配备和升级流程使这一承诺成立。

将地点管理系统视为运营事实来源。存储 E.164 格式的电话号码、保留可读的显示格式、验证邮箱并记录验证时间。在节假日、季节性变化、搬迁、关闭和路由变更前进行审核；自动化比对应标记不匹配而非自行解决。

使用此元素的文章类型

postTypes 前置元数据字段驱动此实现矩阵。

QA 检查清单

• 模块标明一个真实地点，或清楚标识一条组织级别的联系途径。
• 稳定的地点 ID 连接可见模块、运营记录和结构化实体。
• 每一天都有明确的状态，分班制和跨夜时段保留其边界。
• 时间使用地点的 IANA 时区，并在夏令时转换中行为正确。
• 即将到来的节假日、紧急情况和季节性例外情况具有绝对日期，且仅覆盖其声明的范围。
• 「休息」「24 小时营业」和「需预约」状态被明确存储，而非从空白时间推断。
• 每条电话和邮箱途径都有用途标签，并在需要时诚实说明可用性或回复时间。
• 存储的电话号码使用 E.164 格式，显示号码可读，且每个 tel: 和 mailto: 目标均有效。
• 未经批准，不暴露任何个人或无人监控的联系途径。
• 可见模块、JSON-LD、商家信息列表、地图数据和联系操作保持一致。
• openingHoursSpecification、specialOpeningHoursSpecification 和 contactPoint 仅从已验证的可见事实生成。
• 「正在营业」包含下一次时间变化，并在当前状态计算不确定时安全降级。
• 理解基本营业时间或例外情况无需依赖颜色、图标、悬停、展开或 JavaScript。
• 验证日期符合组织的新鲜度策略，数据源不匹配进入自有审核队列。
• Markdown、Hugo 和 WordPress 示例保留相同的类型化时间表、例外情况和联系途径。

常见问题

节假日营业时间是否应替换常规营业时间？

不需要。保留常规每周时间表，并分别发布每个带日期的例外情况。例外情况仅在其指定的日期或范围内覆盖常规时间表，之后自动失效，无需编辑人员恢复常规时间。

商家如何显示其 24 小时营业？

将相关日期标记为「24 小时营业」并明确存储该状态。不要在编写内容中将其编码为 00:00–00:00，因为该组合也被某些结构化数据消费者用于表示休息日，且容易误读。

一个营业时间与联系模块能否覆盖多个地点？

不能作为一个统一的时间表。每个地点应有其独立的标注模块、稳定地点标识符、时区、营业时间、例外情况和联系方式。目录页面可以汇总多个分店，但每行必须可归属于一个分店。

每个联系模块是否都需要同时提供电话号码和邮箱地址？

不需要。它至少需要一条适合该任务的可用联系方式。仅发布组织监控的途径，标注其用途，说明重要的回复或可用性限制，并在某条途径排除部分用户时提供无障碍替代方案。

营业时间应多久验证一次？

每当运营数据源发生变化时，以及在每个已知节假日或季节性转换之前进行验证。同时定期在网站、结构化数据、地点系统和主要商家信息列表之间进行比对；可接受的时间间隔取决于该组织更改营业时间的频率。