使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
直接在里塞虽合法但图文错位、响应式断行、无障碍支持弱；推荐用或配合flex布局实现语义清晰、样式可控的混排。
直接在 <p></p> 里塞 <img> 会出什么问题
可以放，但别指望它“混排”——<p></p> 是块级容器，<img> 默认是行内替换元素，两者语义不冲突，HTML 解析器允许嵌套。但视觉上：文字会按基线（baseline）对齐到图片底边，导致文字悬浮在图片下半部分，上下留白不均；更麻烦的是，一旦图片高度变化或加了 margin/padding，<p></p> 的 line-height 和 vertical-align 就开始失控。
常见误操作：<p><img src="a.jpg">这是说明文字</p> → 看似简洁，实则对齐不可控、响应式时容易换行错位、屏幕阅读器可能把图片和文字当同一语义单元读出。
- ✅ 合法：浏览器不会报错，DOM 结构完整
- ⚠️ 风险：图文间距难统一、移动端易断行、无障碍支持弱
- ❌ 不推荐用于标题图+导语、图标+短提示等需精确对齐的场景
<p></p> 里能用 float 或 display: inline-block 强行混排吗
技术上可以，但属于“打补丁式修复”，隐患比收益多。比如给 <img> 加 float: left，<p></p> 内文字确实会绕排，但会触发 BFC 边界问题，后续兄弟元素可能塌陷；加 display: inline-block 则受父级 font-size 和空白符影响，间隙难以消除。
更关键的是：<p></p> 的语义是“一个完整段落”，而图文混排常含多个逻辑单元（如图标 + 标题 + 描述），硬塞进单个 <p></p> 会破坏可访问性与 SEO 结构。
- ?
float在现代布局中已过时，CSS Grid/Flex 更可控 - ?
inline-block无法解决垂直居中、响应式缩放等基础需求 - ✅ 若必须用旧方案，至少在外层加
<div class="paragraph-figure"> 包裹整个图文块，而非改造 <code><p></p>真正合规又实用的图文混排结构怎么搭
核心原则：让
<p></p>只负责纯文本段落，图文组合交由语义更清晰的容器处理。推荐两种落地方式：- 用
<figure></figure>+<figcaption></figcaption>：适合有明确主图+说明关系的场景，例如新闻配图、教程截图。图和文是并列子元素，<figcaption></figcaption>可放<p></p>，但图本身不进<p></p> - 用
<div class="media"> + Flex/Grid：适合图标+文字提示、头像+简介等 UI 组件。把图片作为独立元素，文字另起 <code><p></p>或<span></span>，靠 CSS 控制布局关系示例（轻量级）：
<div class="media"> @@##@@ <p>这是与图标对应的说明文字，语义独立，样式可控。</p> </div>
再配 CSS：.media { display: flex; align-items: flex-start; gap: 0.5em; }—— 这样既合法，又便于维护和测试。为什么很多人坚持往
<p></p>里塞图片因为早期 CMS 或富文本编辑器（如 TinyMCE、CKEditor）默认把粘贴进来的图转成
<p><img src="icon.png" alt="提示图标"></p>，开发者没改解析规则就直接上线了。久而久之形成惯性，但实际只要改一行配置（比如设置enterMode: CKEDITOR.ENTER_DIV），就能避免这种结构。真正容易被忽略的点是：即使你手动写了合法结构，若后端富文本过滤器（如 DOMPurify）没放开
<figure></figure>或自定义 class，也会被自动剥离——所以图文混排的成败，往往卡在前后端协作的边界上，而不是单纯写法问题。
- 用
