ITU-R BT.2154解读:数字地面电视接收机性能评估与频谱规划实践
做频谱规划和无线覆盖优化的朋友对ITU-R BT系列建议书应该都不陌生。但这个系列编号密集、内容交错真到用的时候很容易挑花眼。最近我把ITU-R BT.2154从头到尾读了一遍又把它用到一次跨系统频率迁移的兼容性评估里这篇文章就当作我的个人解读笔记和应用心得顺便把几个我自己踩过的坑也整理出来。这份建议书的名字听起来有点生僻但它讲的事其实非常落地数字地面电视接收机在真实电磁环境里到底能不能扛得住干扰该怎么评估、怎么设定门限、怎么为后续的频谱规划和台站协调提供依据。简单说它是连接“标准理论”和“工程实务”的一座桥。不管你是做广播覆盖设计、做频谱兼容分析还是做接收设备定型测试想把工作做扎实这份东西都值得认真看。1. 为什么要盯住这份建议书1.1 BT.2154在BT家族里是什么定位ITU-R BT系列里大家接触比较多的可能是关于规划参数、保护率、接收天线性能等内容的建议书。BT.2154虽然也会涉及这些概念但切入的角度不太一样它更侧重于接收端特性与系统可用性之间的对应关系把“接收机能不能用”“在什么条件下能用”这件事讲得比较透。我刚拿到这份文件时第一反应是把它当成又一份“保护率查表工具”。读完之后才发现它更像是一部接收系统性能的评测方法框架。它不会直接告诉你“同频保护率就应该是某个数值”而是告诉你在评价某套数字电视系统时应该测哪些指标、在什么条件下测、数据怎么处理、结论怎么表达。这个思路上的差异非常关键很多人在做频率协调时反复出问题根源就在于把“评测方法”当成了“固定门限表”来用。1.2 建议书到底想解决什么问题现实中地面数字电视的接收场景远没有实验室里那么干净。接收机可能处在城市峡谷里受到多径衰落也可能靠近某个大功率台站面对的是带外强信号还有可能旁边就有其他通信系统的基站在邻频甚至同频上形成干扰。BT.2154解决的核心问题归纳起来就一句话在存在各种实际干扰和信道损伤的条件下如何用一套统一、可重复、可比较的方法去描述一台接收机或者一套接收系统的性能。它强调的是“系统级评估”而非“单点指标”。这个定位让它特别适合用来做以下几类工作频谱规划前评估某种网络制式和另一种系统能否在同一个频段共存台站协调时判断某新增大功率台站是否会影响已有覆盖区设备选型时对比不同厂商接收机在实际信道条件下的性能差异把国际建议转成国内或地区层面的工程技术规范。我做频率迁移评估时最头痛的往往不是某个参数怎么算而是双方用的衡量标准压根不统一。A系统用某参考接收机的误码率说话B系统用另一个标准里的场强门限说话两边对不上工作就没法推进。BT.2154提供的正是这种“把大家拉到同一个坐标系里”的方法。2. 建议书核心要素拆解2.1 四个关键维度我读这份建议书时发现它的技术内容基本围绕四个维度展开。第一个维度是系统与接收机类别。数字地面电视不是只有一种形态有固定接收、移动接收、便携接收接收天线也有方向性天线、全向天线、有源天线之分不同组合下的性能曲线差异极大。建议书要求评估时必须明确这一前提否则后面的所有数据都没有意义。第二个维度是干扰场景定义。同频干扰、邻频干扰、以及干扰信号来自广播系统还是非广播系统处理方式完全不同。尤其是邻频场景涉及发射频谱的滚降特性、接收机前端滤波器的抑制度还有两者之间的频率间隔。很多人在邻频问题上栽跟头就是只盯着中心频点差了几兆赫忽略了实际频谱掩蔽形状。第三个维度是信道条件设定。高斯信道、多径信道、动态衰落信道性能结果可以差出好多个dB。建议书里通常会给出参考的信道模型或者至少要求评估者说明自己采用了什么信道条件。这部分也是最容易被跳过、但在实际工程里影响最大的一个环节。第四个维度是性能判据与统计口径。大家习惯用“误码率”“误包率”来衡量接收质量但问题是取什么时间窗口、在什么置信度下统计。不同判据之间看似接近实操出来的结果可能差异很大。建议书是为数不多会对这类统计口径做出周密要求的文件之一。这四个维度加起来基本构成了一套完整的“接收性能评估坐标系”。2.2 保护率与射频指标的对应关系BT.2154反复强调接收系统的整体射频特性这和传统的保护率概念是互相成就的关系。传统上我们谈保护率说的是在某个给定干扰信号下要维持接收质量有用信号和干扰信号之间需要保持的最小强度差。而BT.2154明确要求这个差值不是凭空定的它最终要落实到具体接收机在真实信道条件下的射频表现上。举个例子假设某组保护率参数是在多径信道下测出来的那么你的接收机就需要对多径衰落有一定的均衡能力如果保护率参数是在高斯信道下测出来的接收机对动态多径的耐受能力则没有经过验证。同样的保护率数字背后的“接收机实现成本”可能完全不同。这就是为什么我不建议把它当单纯的门限表读。它实际上是在提醒你保护率只是评估链条中的一环前面有信道模型后面有接收机类别再往后还有天线增益和馈线损耗。只有把这一整条链条合起来看得到的可用场强才有工程意义。2.3 接收天线与分集处理的两个细节天线参数是BT.2154里比较容易被忽视但又很重要的部分。建议书在讨论接收性能时通常不是指天线端子之前的部分而是把天线、馈线、接收机看成一个整体。第一个细节是天线方向性。测试中如果用了高增益定向天线实际上相当于天然提供了一部分同频干扰抑制能力而采用全向天线时这部分抑制能力就没了。很多小型发射台在做覆盖评估时默认接收端是家用八木天线但实际用户可能用的是室内天线或便携设备两者的可用场强差出一大截。这不是接收机不行是评估前提和实际场景错位了。第二个细节是分集接收。空间分集、极化分集、时间分集这些技术对移动和便携接收的改善是非常明显的。建议书在涉及移动接收时通常会允许评估分集增益但前提是要把分集方式、天线间距、合并算法等交代清楚。否则一套使用分集的接收系统测出来的漂亮曲线拿到单天线场景里根本复现不出来。我在做实际评估时习惯把“天线场景”单独列一张表把固定高增益、固定中增益、便携天线、车顶天线几种典型配置的参数全部写清楚。这样做的好处是定出来的门限不会被质疑“你用的是哪家的天线”。3. 落地从标准文本到工程实施3.1 一个可复用的五步工作流把BT.2154的方法论落到实际项目里我习惯按下面五步走。第一步明确评估对象和使用场景。比如是“某城市市区内固定接收屋顶天线评估某新增邻频基站对现有广播覆盖的影响”还是“某高速沿线车载移动接收两套发射系统同频切换”。这一步不做好后面全是空中楼阁。第二步确定参考接收系统模型。根据第一步选定的场景确定接收机类别、天线类型、馈线损耗、分集方式并把这些参数整理成一个统一的参数表。参数表里每一项都要有出处用建议书里的就用建议书里的用不了的就注明是实测还是厂商数据。后面评审时这份参数表就是最有力的依据。第三步建立干扰与信道模型。确认干扰信号是什么类型、频谱形状如何、以及与有用信号在时域和频域上的相对关系确认信道是高斯、多径还是动态衰落。这一步需要结合具体频段的传播模型来做。我通常会把几种典型信道条件都跑一遍而不是只跑最理想的那一个。第四步计算或实测得到关键性能曲线。有条件的做实测没条件的做仿真。实测的注意点是设备链路校准仿真的注意点是信道模型参数要与建议书保持一致尤其是多径延时谱和衰落统计特性。第五步把性能结果转成规划需要的参数。这一步就是把保护率、最小可用场强这些算出来再叠加天线增益、馈线损耗、接收端位置概率因子等形成规划或协调用的门限值。3.2 简易参数模板参考下面这个参数模板是我在项目中整理的一个简化示例覆盖了BT.2154落地时经常会到的核心字段。真正使用时你可以把它扩展成更细的输入文件供仿真软件或测试系统读取。evaluation_scenario: scene_type: fixed_rural receive_mode: rooftop terrain_category: flat_terrain receiver_chain: antenna_model: pattern: directional gain_dbi: 12 front_to_back_ratio_db: 18 feeder_loss_db: 2.0 receiver_category: class_a diversity_enabled: false interference_scenario: source_system_id: other_imt protection_ratio_same_channel_db: 24.0 frequency_offset_mhz: [0, -10, 10] adjacent_channel_rejection_db: 34.0 channel_profile: - name: gaussian doppler_hz: 0 delay_spread_us: 0 - name: typical_urban_6tap doppler_hz: 20 delay_spread_us: 2.5 performance_criteria: target_ber_before_rs: 1E-4 measurement_window_s: 10 availability_percent: 99.0我特别想提醒的是模板里的“protection_ratio”和“adjacent_channel_rejection”这两个值不同项目里差异巨大。它们取决于双方的系统制式、带宽、频谱遮蔽、接收机前端性能等一系列因素。所以模板里的数字只用于演示格式实际项目别直接抄。3.3 测试与仿真怎么衔接待遇测试和仿真在BT.2154框架下经常是配合使用的单纯靠一条路走到底很容易出偏差。实测的优点是结果真实可信缺点是场景覆盖面太窄。现场往往只能提供某个特定地点的信道条件你测出来的性能曲线只能代表“那个位置的那个时刻”。仿真则相反可以任意切换信道模型和干扰配置但结果的可信度又取决于仿真器对接收机内部算法的还原程度。我的做法是“仿真为主、实测校准”。先在仿真环境里搭一套参考接收机模型把BT.2154建议的典型信道场景全部跑一遍得到基准性能曲线然后再选两到三个典型地点做实测把实测数据和仿真数据放在一起对比。如果偏差在合理范围之内说明仿真模型可信可以直接用仿真结果去推演更大范围的覆盖和干扰场景如果偏差大就先排查模型细节再补测。这样做的直接收益是在跟上下游单位讨论时我至少能说清楚“这条曲线是仿真出来的在哪个点位上做过实测校准模型置信区间是多少”而不是甩出一堆没有依据的仿真曲线让人质疑。4. 常见坑与实战笔记4.1 掉进“静态门限”陷阱使用该建议书时最容易犯的错误是把某一套参考场景下得到的保护率或可用场强直接当成全局门限用。我见过一些项目里把一份报告里某组邻频保护率数字挪用到另一个完全不同的场景理由是“大家都是数字电视差不了太多”。结果就是两个系统在某个区域互相干扰实际收听画面出现卡顿甚至黑屏而按纸面数据去查又完全在“允许范围”内。问题不在某个环节算错而是评估前提根本没对齐。正确做法是每做一个新场景都要回到BT.2154的评估框架里重新走一遍流程至少要把接收机类别、信道条件、干扰频谱特性这些关键前提重新确认一次。哪怕最后结论和参考门限很接近这个过程也不能省因为你得能向别人证明这个结论是在合理前提下推出来的。4.2 天线方向图和极化方式被拍脑袋忽略天线因素在标准解读里最容易被“一句话略过”但在实际工程里它是影响全局的变量。同样是12 dBi增益的八木天线不同产品的方向图旁瓣水平可能差出好几个dB而旁瓣特性直接决定了对来自侧后方干扰的抑制能力。如果评估时用的天线方向图是标准理想化的但实际台站周边用户安装的天线方向图不是那么理想实际可用场强就会往下掉。还有一个更隐蔽的问题是极化方式。很多评估默认收发同极化但实际用户接收天线的极化方式不一定与发射一致。尤其是在城区室内接收天线五花八门极化失配造成的损耗可能达到10 dB以上。建议书在讨论接收系统时其实隐含了“极化要匹配”的假设但如果你把移动接收、室内接收也硬套这个假设结果就会偏乐观。我在实际参数表里永远留两行给天线极化匹配损耗和方位角偏差损失哪怕初始取值保守一些也好过完全不留余地。4.3 从建议书到执行规范之间还有大量翻译工作BT.2154是国际建议不等于任何地区的强制标准。它在落地时还要结合本地的频率划分表、台站管理规定、设备认证制度以及典型的用户接收场景才能变成可执行的技术要求。这个“翻译”过程很容易出现两类问题。一类是把建议书内容全盘照搬不管本地实际情况另一类是本地部门有自己的历史规定与国际建议产生出入又没说清楚取舍逻辑。两种做法都会给后续的频谱协调和台站管理工作埋雷。我的经验是尽量在项目评审层面就把“标准依据”和“落地规则”分开表述。哪些条款直接引用ITU-R BT.2154哪些是根据实际情况作了调整调整的工程技术理由是什么全部落到纸面上。这样做既能保持国际建议在方法论上的指导作用又能让本地执行规则有可操作性还方便日后再做修订时追溯。4.4 实测链路校准不严谨导致方向性偏差实测环节最容易出问题的往往不是接收机本身而是整个测试链路里那些不被注意的细节。比如测试电缆的损耗在每一个频率点是否都做了校准比如干扰信号合成器的相位噪声是否够低又比如频谱仪的分辨率带宽是不是设得太宽而把有用信号能量漏掉了。这些看起来都是基本功但一次完整的系统性能评估涉及到的器件和连接环节非常多任何一个环节出问题最终结果都可能偏差几个dB。而几个dB在频率协调里往往就决定了两个系统能不能共存。我个人的习惯是每次实测开始之前先做一次全链路的通断校准记录每根线缆、每个转接头、每个功放的插损同时用一台已知性能的参考接收机做正反向验证确保测试系统本身没有引入额外误差。这个流程不算复杂但能让你省下后面无数的返工。4.5 把“规划参数”和“实测参数”混为一谈最后一个很容易踩的坑是把规划用的统计参数和实测用的瞬时参数混在一起用。规划参数往往是中长期统计意义上或者覆盖概率意义上设定出来的实测参数则是某一次特定测试条件下得到的。比如覆盖规划里经常说“50%位置、70%时间”的可用率这是一个统计目标。但你拿某一次路测里看到的一个瞬时误码率数字去评判整张网的覆盖是否达标这就不对了。反过来也一样不能因为一次路测在某一点表现很好就认为整个区域都满足规划指标。BT.2154里面会有关于测量时间窗口和统计判据的交代实际应用时你必须把这些统计条件和规划目标严格对应起来。我见过一些团队把建议书里推荐的测试时长砍掉一大半理由是为了节约测试时间最后得出来的结果波动非常大根本没法用来支撑结论。这里我的态度很明确除非你论证过更短窗口的统计置信度仍然符合要求否则不要轻易缩短测试时长。5. 最后说几点个人体会把这份建议书反复用了几轮之后我最大的感受是它的价值不在于给你一个放之四海而皆准的数字而在于逼你建立起一套严谨的表达习惯。做这一行时间长了会发现频谱管理和无线覆盖领域很多争论本质上不是技术高低之争而是前提条件没有对齐。你用的信道模型和他用的信道模型不一样你测误码的时间窗口和他测误包的时间窗口不一样讨论自然就是鸡同鸭讲。BT.2154做的事情恰恰是把这个扯皮空间压缩到最小让你在开口说“这个门限够不够”之前先把“我们在什么条件下谈这个门限”说清楚。另外还有一点小心得是这个标准其实后续可能会配套一些新的测试案例和更新建议平时关注一下版本变化。我自己的做法是把标准里所有引用的参考文件都单独列一个文件夹定版本、定索引、定期复查因为这类文件之间的引用关系非常紧密一旦某个上游文件更新很多参数含义都要重新理解。如果你正准备用这份建议书去做频率协调或者设备评估我的建议很简单别急着跳到保护率那几页先把评估场景、接收机类别、信道条件这几个前提敲定。前提稳了后面每一步都是水到渠成前提松了后面就是拿着一张浮动的地图找路越找越乱。就分享到这里。后面有具体的场景细节想讨论的欢迎留言我看到再结合自己的项目经验补充分享。

相关新闻

网络安全密码学核心考点:从古典密码到数字签名复习指南

网络安全密码学核心考点:从古典密码到数字签名复习指南

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/14 3:56:41 阅读更多 →
FFmpeg Bitstream Filter原理与实战:码流语法转换核心技术

FFmpeg Bitstream Filter原理与实战:码流语法转换核心技术

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/14 3:56:41 阅读更多 →
STM32F030R8Tx使用HAL库实现ADC DMA多通道采集与问题排查

STM32F030R8Tx使用HAL库实现ADC DMA多通道采集与问题排查

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/14 3:56:41 阅读更多 →

最新新闻

一文搞懂MySQL socket连接:原理、配置与2002/2003故障排查

一文搞懂MySQL socket连接:原理、配置与2002/2003故障排查

一次线上事故让我把socket连接这件事彻底搞明白了。当时某个项目组反馈所有本地应用突然连不上MySQL,我登录服务器一看,mysqld进程明明活着,3306端口也在正常监听,可本地应用全部报socket错误。查了半个多小时,最后发现…

2026/10/14 4:45:56 阅读更多 →
最大熵补丁采样:让少样本分类模型学会“看哪里”

最大熵补丁采样:让少样本分类模型学会“看哪里”

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/14 4:45:56 阅读更多 →
个人开发者软著申请全流程指南:材料准备、提交与避坑要点

个人开发者软著申请全流程指南:材料准备、提交与避坑要点

软著这个东西,说白了就是给软件“上户口”。我是从独立开发那会儿开始接触的,一开始也觉得麻烦,无非就是写代码的人做点文档工作。但真正自己走完一遍以后,才发现里面门道不少,很多细节不去实际踩一遍根本想不到。这篇…

2026/10/14 4:45:56 阅读更多 →
JavaScript基础核心概念详解:变量、类型、函数、闭包与异步

JavaScript基础核心概念详解:变量、类型、函数、闭包与异步

我教过不少刚接触代码的人,发现大家学 JavaScript 都会经历同一个尴尬阶段:跟着教程能写出例子,合上教程就不知道下一步该干嘛。原因很简单——基础概念没有变成自己的。这篇文章是「JavaScript 基础」系列的第一讲,目标只有一个&…

2026/10/14 4:45:56 阅读更多 →
Modbus报文从入门到实战:帧结构、寄存器映射与CRC校验详解

Modbus报文从入门到实战:帧结构、寄存器映射与CRC校验详解

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/14 4:45:56 阅读更多 →
Personal Agent 省钱实战:从订阅替代到混合架构搭建

Personal Agent 省钱实战:从订阅替代到混合架构搭建

1. 从一条动态说起:Personal Agent 到底在解决什么问题前阵子刷到一条动态,标题大意是“又一 Personal Agent 发布,帮我省下不止200刀”。评论区一半人在问“这玩意儿到底能干啥”,另一半人在晒自己的订阅账单——原来大家每个月花…

2026/10/14 4:44:56 阅读更多 →

日新闻

AnyPS5通用适配层设计:兼容性与性能的工程取舍

AnyPS5通用适配层设计:兼容性与性能的工程取舍

1. 从"AnyPS5"这个名字说起:它到底想解决什么问题第一次看到"AnyPS5"这个标题,我脑子里冒出来的第一个念头是:这大概率是一个围绕"跨平台运行"或者"通用适配"做文章的项目。名字里的"Any"…

2026/10/14 0:00:41 阅读更多 →
Flutter跨平台开发实战:二手交易应用与HarmonyOS适配

Flutter跨平台开发实战:二手交易应用与HarmonyOS适配

1. 项目概述:Flutter跨平台二手交易应用开发作为一名长期从事移动应用开发的工程师,我最近完成了一个基于Flutter框架的二手物品交易平台项目。这个项目最吸引我的地方在于它完美结合了Flutter的跨平台优势与HarmonyOS的生态特性,实现了"…

2026/10/14 0:00:41 阅读更多 →
DFS算法解决飞机降落调度问题实战

DFS算法解决飞机降落调度问题实战

1. 项目背景与核心思路飞机降落问题是一个经典的调度优化场景,也是算法竞赛和面试中的高频题目。这个题目要求我们合理安排多架飞机的降落顺序和时间,确保所有飞机都能安全着陆而不发生冲突。在实际航空管制中,这类问题直接关系到飞行安全和机…

2026/10/14 0:00:41 阅读更多 →

周新闻

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

流感时间序列预测实战:ARIMA/LSTM全流程拆解与避坑指南

简介:基于 ARIMA、LSTM、Transformer 等模型的流感时间序列预测 Python 源码,面向计算机相关专业课程设计与期末大作业学生,以及项目实战学习者。内容覆盖预处理、平稳性检验、定阶、残差分析、多模型对比预测的完整时序建模流程,…

2026/10/14 3:30:28 阅读更多 →
影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别

影刀RPA新手教程:键盘模拟输入实战——输入文本与模拟按键的区别 做影刀RPA自动化,十个新手有八个栽在"往输入框里填东西"这件事上:要么填不进去,要么填了一半,要么直接把原来内容追加在后面。这背后的根因&…

2026/10/13 16:22:04 阅读更多 →
影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容

影刀RPA新手教程:阅文起点小说数据采集实战——书籍信息与章节内容 1. 认识影刀:什么场景该用RPA采小说数据 起点中文网的页面结构相对稳定——分类榜单、书籍详情、章节内容三块独立页面,跳转链路清晰。这种场景非常适合影刀自动化&#x…

2026/10/14 3:29:58 阅读更多 →

月新闻

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

我发现了一个新思路:用 Remotion + Claude Code 像写代码一样自动化生成短视频

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/13 22:01:27 阅读更多 →
Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式:TaoToken 统一 Key 配置与验证

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/13 14:57:39 阅读更多 →
黑夜航拍船只数据集训练YOLOV5模型全流程解析

黑夜航拍船只数据集训练YOLOV5模型全流程解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

2026/10/12 18:11:17 阅读更多 →