提取列表项需先用soup.prettify()检查实际解析结构，优先选"html.parser"解析器，用get_text(strip=True, separator='|')处理文本，兼顾div/p等非li标签及data-role属性。
用 find_all() 提取所有 li 标签前先确认结构是否被浏览器“修复”过
很多 HTML 源码里 ul 或 ol 并没闭合，或者嵌套了非法标签（比如 li 里直接塞 div），浏览器解析时会自动补全或拆解，导致你用 soup.find_all('li') 拿到的节点顺序错乱、数量对不上。先运行 soup.prettify() 看一眼实际解析出的结构，重点检查：li 是否都包在 ul/ol 里、有没有被截断成孤立节点、是否存在空 li（如 <li>）。若发现异常，换解析器：优先用 "html.parser"，它比 "lxml" 更宽容，不易因 <script></script> 未闭合就提前终止。
get_text(strip=True) 是标准操作，但列表项常需保留换行逻辑
直接调 .text 会把 li 内所有子元素（strong、a、span）的文本无差别拼接，还可能混入不可见字符（如零宽空格 \u200b）。必须用 .get_text(strip=True)。若想让每项占一行，加 separator='\n'；若后续要导入 Excel 或做分词，用 separator=' | ' 更稳妥。遇到这种结构：<li>苹果<span class="price">¥5.8</span>
</li>，.get_text() 返回 “苹果¥5.8”，但你可能需要分离价格——那就得手动遍历 li.children，跳过 Tag 只取 NavigableString。
别只盯 li，有些“列表”根本没用语义化标签
微信公众号、Notion 导出页、CMS 后台生成的内容，常把列表项写成 div + class（如 class="list-item" 或 class="bullet"），甚至用 p 加特殊符号（•、-、→）模拟。硬靠 find_all('li') 会漏掉大半。应先试探：soup.find_all(['li', 'div', 'p'], class_=re.compile(r'list|item|bullet|dash'))，再人工抽检几条输出，看是否覆盖目标。若 class 名太随意，可 fallback 到 CSS 选择器：soup.select('ul li, .content > p:not([class])')，但注意 :not() 在 "html.parser" 中不支持，得换 "lxml" 或改用正则过滤。
把任意文章或文档内容转换成精美的全屏翻页 HTML 演示文件（幻灯片风格）。当用户发来一篇文章、文档链接、Markdown 内容、或粘贴的文本，并且希望生成演示用的 HTML 时触发。支持任意内容来源：iWiki 链接、KM 链接、本地文件路径、直接粘贴的文本。生成的 HTML 文件保存到本地工作区，并通过企微直接发送给用户。触发词示例：帮我把这篇文章做成PPT、转成演示文档、生成HTML幻灯片、做个演示、转成可以演示的格式、article to deck、make a slide。
批量处理多个 HTML 文件时，空项和编码异常最易卡住流程
常见阻塞点不是语法错误，而是静默失败：li 提取后为空字符串、文件读取时抛 UnicodeDecodeError、某一页含 BOM 头导致首字符乱码。建议每步加 guard：
– 过滤空内容：[li for li in soup.find_all('li') if li.get_text(strip=True)]
– 统一用 encoding='utf-8-sig' 打开文件，自动吃掉 UTF-8 BOM
– 提取后立即清洗：text.replace('\u200b', '').replace('\xa0', ' ').strip()
– 用 repr() 打印前 3 条结果，肉眼确认有无异常 Unicode
立即学习“前端免费学习笔记（深入）”；
真正难的不是写对那几行代码，是拿到一份 HTML 后，花 30 秒判断它到底算不算“标准列表”——有时候li 是假的，div 才是真的，而那个不起眼的 data-role="list-item" 属性，才是唯一可靠线索。 
