Chrome 中 Emoji 表情颜色缺失的渲染问题
问题背景
昨天在写为什么这么设计系列文章时，心血来潮在 <h1>, <h2>, <h3> 等标题标签中加上了色彩鲜明的 Emoji，增强标题区的对比度。
写作时——开两个窗口，边撰写边实时预览——一切都正常显示，但是一经发布，在电脑端的 Chrome 浏览器中就发现了个诡异现象，正文和目录中的表情显示正常，但是在标题中渲染成了一副傻大黑粗的模样🌑，五颜六色，惨遭剥离，独留黑白，茕茕孑立，形影相吊，不忍直视。
2021年12月
为什么 Python 需要 if __name__ == "__main__" 语句
为什么这么设计（Why’s THE Design）是一系列关于计算机程序设计中决策的文章，在这个系列的每一篇文章中都会提出一个具体的问题，并从不同的角度讨论这种设计的优缺点、对具体实现造成的影响。
🙋♂️ 简要回答
TL;DR
这样的机制是保护用户在无意中调用脚本中的代码。以下面的脚本为例子：
使用 PrismJS 实现代码语法高亮
问题背景
虽然 Typecho 原生支持 Markdown 语法，但是代码块部分只是用等宽字体+颜色置灰进行简单装饰，并不能像 Github 那样运用丰富多彩的颜色规则来高亮代码。然而没有颜色的代码，就像没有了灵魂，可读性可谓是呈断崖式下降，关键字、变量名和函数名都不分你我，共灰白一色。
我的需求
为了可读性，建站之后，代码高亮便提上日程。我梳理了自己的需求，主要有
- 着色代码: 语法高亮
- 多种语言：基础的包括
JS,PHP,Go,Python和C/C++等，后续如果要学习Rust或TS希望能方便地接入 - 软件生态：使用的人数多不多，代码更新迭代是否勤快，Issue 处理及时性
- 可扩展性：能否扩展小功能？如代码支持拷贝，左侧显示行数，显示所用语言
- 方便部署：部署时会考虑代码包压缩后的大小，是否容易嵌入已有的代码结构中
删除项目中的 pyc 文件和 __pycache__ 文件夹
问题背景
项目中每个模块下都有为数不少的 Python 文件，当做了一些局部的修改，需重启服务验证想法时，不要使用旧版的系统缓存的 pyc 编译文件，而是修改后的 Python 文件。