通过每个主要WordPress更新，主题作者可以访问新工具，以减少其开发工作量并可以提高主题的性能。最后几个版本中的大多数改进都来自theme.json更新。
这theme.json文件添加了额外的设置和样式，可以替代自定义CSS的需求。这些样式是内衬的，并根据需要输出。 主要的WordPress更新通过JSON格式不断为主题作者带来了更多的控制。
块系统发光的另一个区域是其用于加载每块样式的功能。 当WordPress在特定前端视图上检测到特定块时，它将内联该块的CSS内部<head>网站的要素。 它对第三方块以及来自Core的块来做到这一点。
总而言之，这是一个高效的系统。而且，当整个站点由块（例如块主题）组成时，WordPress通常只能在任何给定的前端视图所需的CSS位置有效地内联。
包裹所有CSS的潜在缺点是您在浏览器缓存中损失了。但是，考虑到过去十年中许多WordPress主题的样式表的大小激增，块系统很可能比普通的经典主题更有效。但是该系统只能与最弱的组件一样好。这给主题作者的肩膀带来了许多责任，以利用可用的工具。
为了帮助鼓励最佳实践，让我们谈谈确保表演主题的两个主要工具：theme.json和按块样式。
利用theme.json样式
在现代建立WordPress主题要求开发人员重新考虑他们过去依赖的方法。它要求他们依靠WordPress进行大部分繁重的举动，在某种程度上无法控制自己的基础上“全部进入”。
主题的主要作用与往常一样。这是设计，油漆覆盖房屋的墙壁。但是，基础体系结构都是在标准系统之上构建的。
这会带来一些优点，例如允许所有扩展名（包括插件和主题）受益于相同的性能相关功能。
过去，主题设计是style.css，但事实并非如此。主题作者通过其样式表创建了很多（并非全部）已纳入theme.json。对于那些舒适的编写CSS的人来说，这可能有些令人反感。那是可以理解的。但是，在舒适区之外迈出一步可能意味着走进一个新的和奇妙的可能性世界。
JSON的使用是允许WordPress，主题和用户进行交流，共同构建网站的框架的一部分。WordPress提供界面以及默认设置和样式。主题使用theme.json覆盖默认值。用户可以通过界面进行自己的自定义，该界面本质上是存储在数据库中的自定义JSON。
因为所有这些都存在于此标准框架内，所以这意味着在整个生态系统中，新版本的WordPress的每个性能都会提高。
这些好处需要从主题作者那里获得买入。要从现代WordPress那里获得最大收益，开发人员必须使用theme.json在转到基于样式表的解决方案之前，要配置尽可能多的视觉外观。它是块主题开发的基础，但是经典主题作者也可以利用它。
这 theme.json页面 在主题手册中是开始学习如何使用的最佳场所theme.json。而且，生活参考 在Block编辑器中，手册维护了设置和样式的最新参考。特别是，主题作者应始终检查是否有 样式选项 在访问自定义CSS之前可用。
每个自定义CSS规则放在theme.json还可以从阻止使用的同一上下文，内联风格的系统中受益。
每块样式
theme.json不是一个神奇的子弹，可以治愈主题作者试图解决的每个问题。它是一种应在最大程度上使用的工具。并非所有选项当前都可以通过JSON访问，并且有时使用样式表有意义。但是，长期目标是使用尽可能少的自定义CSS。
传统上，每当主题作者想添加一些设计才能（或实际上是任何CSS）时，他们都会在主题的主题中添加代码style.css文件。在WordPress的早期，主题在低于10 kb的范围内具有未限制的，未压缩的样式表并不少见。网络较慢，网站更简单。随着网站的复杂性的增长，样式表的尺寸遵循。
以下是经典时代的最后三个默认主题及其style.css文件大小：
- 二十一个： 158 kb
- 二十二十： 125 kb
- 二十十九： 228 kb
与许多第三方主题相比，这三个主题具有相对简单的设计。网站及其样式表尺寸的复杂性日益增长，是块系统试图解决的问题。
虽然未来的默认WordPress主题可能主要依赖theme.json为了他们的设计需求，外界的开发人员经常会发现自己要追求style.css通过通过theme.json。
那就是那里wp_enqueue_block_style()进来。它允许主题作者利用WordPress和Block插件免费获得相同的内联系统。此功能使主题作者可以分解其样式表的单个块，仅在需要时将其添加为内联样式。
让我们来看看一个实用的例子。假设您需要一些自定义CSS应用于核心组块。假设您的文件位于主题中assets/blocks/core-group.css文件，使用主题函数中的以下代码。
add_action( 'init', 'themeslug_enqueue_block_styles' );
function themeslug_enqueue_block_styles() {
wp_enqueue_block_style( 'core/group', array(
'handle' => 'themeslug-block-group',
'src' => get_theme_file_uri( "assets/blocks/core-group.css" ),
'path' => get_theme_file_path( "assets/blocks/core-group.css" )
) );
}与相关wp_enqueue_*功能，您必须将FilePath与URL路径一起提供给CSS文件。这是因为WordPress需要获取文件的内容并在其中打印<head>元素。
以上是一个过于简单的例子。主题作者很可能需要加载多个文件，并且为每个样式表重写相同的代码将成为一场管理噩梦。
在为多个块上制定样式时，请使用阵列并循环通过它们。以下代码段假设您对核心按钮，标题和段落块具有样式表：
add_action( 'init', 'themeslug_enqueue_block_styles' );
function themeslug_enqueue_block_styles() {
// Add the block name (with namespace) for each style.
$blocks = array(
'core/button'
'core/heading',
'core/paragraph'
);
// Loop through each block and enqueue its styles.
foreach ( $blocks as $block ) {
// Replace slash with hyphen for filename.
$slug = str_replace( '/', '-', $block );
wp_enqueue_block_style( $block, array(
'handle' => "themeslug-block-{$slug}",
'src' => get_theme_file_uri( "assets/blocks/{$slug}.css" ),
'path' => get_theme_file_path( "assets/blocks/{$slug}.css" )
) );
}
}您可以对此更加谨慎，并使用PHPglob()函数可以自动生成文件数组。但是，上述代码的目标是让您在工作中查看其机制。
对于那些想知道的人core-文件名的前缀以及对str_replace()打电话，有充分的理由。它以这种方式设置pluginslug/blockslug和文件名喜欢pluginslug-blockslug.css。如果您仅计划支持主题中的核心块，则可以始终简化代码。
对于许多块主题，将不需要style.css完全文件，除了添加带有主题名称和其他详细信息的文件标头信息之外。当页面上的每个元素都是一个块时，几乎不需要其他很多。当然，有一些场景属于此范围，但是大多数主题CS可以通过theme.json和按块样式。
道具 @Juanmaguitar，@Annezazu，@Mburridge，@WebCommsat，和 @BPH 用于反馈和审查。