3个核心算法手写我爱电子书解析，告别面试卡壳
面试官问：“如果让你从零手爱一个电子书阅读器，核心数据结构怎么设计？内存怎么控制？”
你心里慌了：平时只看过源码，没真正写过。
实战项目里，光会调用库没用，得懂底层。
项目目标与需求拆解
别被“电子书”三个字吓住。
对于应届生来说，核心不是做UI，而是处理文本流、分页渲染和状态同步。
我们要实现一个最小可用版本（MVP），支持 TXT 格式解析、分页显示、目录跳转。
这能覆盖 80% 的底层逻辑面试考点。
为什么选 TXT？
PDF 涉及字体渲染、矢量图形，太复杂。
TXT 是纯文本，逻辑清晰，适合手写核心算法。
官方文档中，W3C 标准对文本换行规则有明确定义，但手写时我们简化处理，只处理硬换行（\n）和软换行（宽度溢出）。
功能清单：解析器：读取文件，分块加载，避免一次性读入内存。
排版引擎：根据屏幕宽度，计算每页行数。
视图层：Canvas 或 DOM 渲染，这里用 Canvas 更贴近原生。
交互：上下翻页，目录树展开。避坑提醒：
很多初学者喜欢一开始就搞 Markdown 支持。
错。
先把纯文本跑通，再谈扩展。
贪多嚼不烂，面试时讲不清楚，反而扣分。
目录结构设计
好的目录结构，是代码可维护性的基石。
我们采用模块化设计，职责单一。
ebook-reader/
├── index.html # 入口页面
├── main.js # 应用初始化
├── core/
│ ├── parser.js # 文本解析器
│ ├── paginator.js # 分页算法
│ └── renderer.js # Canvas 渲染器
├── utils/
│ ├── fileLoader.js # 文件异步加载
│ └── logger.js # 调试日志
└── styles.css # 基础样式核心模块说明：parser.js：负责将原始字符串转为结构化行数组。
paginator.js：输入行数组和页面高度，输出每页的行号范围。
renderer.js：根据行号范围，在 Canvas 上绘制文本。为什么这样分？
面试时，你能画出这个依赖图，说明你有架构思维。
所有模块通过接口交互，不直接操作 DOM 或文件。
这样方便单元测试，也方便后续替换渲染层（比如从 Canvas 换成 WebAssembly）。
细节注意：
utils/fileLoader.js 使用 fetch API 异步读取本地文件（需配合 HTTP 服务器）。
如果面试现场是纯前端环境，可以模拟 Promise 返回字符串。
核心代码实现：解析与分页
这是面试最容易被问倒的部分。
分页算法不是简单的 slice，要处理长行断行。
1. 文本解析器 (parser.js)
/*** 将文本内容解析为行数组* @param {string} content - 原始文本* @returns {Arraystring} - 行数组*/
export function parseText(content) {// 统一换行符，处理 \r\n, \r, \nconst normalized = content.replace(/\r\n?/g, '\n');// 分割为行const lines = normalized.split('\n');// 过滤空行？不，保留空行，用于段落间距计算// 这里返回原始行，排版时再处理return lines;
}逐行讲解：replace(/\r\n?/g, '\n')：Windows 用 \r\n，Mac 用 \r，Linux 用 \n。统一成 \n 是基础功。
split('\n')：得到数组，每个元素是一行文本。
关键点：不要在这里做断行。断行是排版引擎的事。解析器只管“切块”。2. 分页算法 (paginator.js)
这是难点。
假设屏幕高度 800px，行高 20px，页边距 50px。
每页可显示行数 = (800 - 50*2) / 20 = 35 行。
但如果有超长单词，一行放不下怎么办？
我们需要一个简单的贪心断行算法。
/*** 简单贪心断行算法* @param {string} text - 单行文本* @param {number} maxWidth - 最大像素宽度* @param {number} fontSize - 字体大小* @returns {Arraystring} - 断行后的子行*/
export function breakLine(text, maxWidth, fontSize) {// 简化：假设每个字符宽度等于 fontSize * 0.5// 实际项目中需用 Canvas measureTextconst charWidth = fontSize * 0.5;const maxChars = Math.floor(maxWidth / charWidth);if (text.length = maxChars) {return [text];}const result = [];let remaining = text;while (remaining.length maxChars) {// 找到最后一个空格，避免单词切断let cutPos = remaining.lastIndexOf(' ', maxChars);if (cutPos === -1 || cutPos maxChars * 0.5) {// 没找到合适空格，硬切断cutPos = maxChars;}result.push(remaining.substring(0, cutPos));remaining = remaining.substring(cutPos).trimStart();}if (remaining.length 0) {result.push(remaining);}return result;
}避坑指南：硬切断：如果没有空格，强行切断。中文没有空格，直接按字符数切。
性能：这个算法是 O(n)，对于长文本没问题。
面试话术：可以提一下，生产环境会用 Canvas.measureText 获取精确宽度，但手写时简化为估算，体现工程权衡。3. 分页主逻辑
/*** 计算分页* @param {Arraystring} lines - 解析后的行* @param {number} linesPerPage - 每页行数* @returns {ArrayArraynumber} - 每页包含的行号索引*/
export function paginate(lines, linesPerPage) {const pages = [];let currentLineIdx = 0;// 先对所有行进行断行处理，得到“逻辑行”const logicalLines = [];lines.forEach(line = {// 假设 fontSize=16, maxWidth=600const broken = breakLine(line, 600, 16);broken.forEach(bl = logicalLines.push(bl));});// 按逻辑行分页for (let i = 0; i logicalLines.length; i += linesPerPage) {const pageLines = logicalLines.slice(i, i + linesPerPage);// 这里简化，实际应记录原始行号以便目录跳转pages.push(pageLines);}return pages;
}注意：
上面代码为了演示清晰，做了简化。
实际项目中，paginate 应该返回 { startIndex, endIndex }，而不是直接返回文本，这样渲染器可以按需加载。
运行与测试：Canvas 渲染
代码写完了，得跑起来。
我们用一个简单的 Canvas 渲染器。
// renderer.js
export class CanvasRenderer {constructor(canvas) {this.canvas = canvas;this.ctx = canvas.getContext('2d');this.fontSize = 16;this.lineHeight = 20;this.margin = 50;}renderPage(pageLines, pageIdx) {this.clear();this.ctx.font = `${this.fontSize}px sans-serif`;this.ctx.fillStyle = '#333';let y = this.margin;pageLines.forEach((line, index) = {// 绘制每行文本this.ctx.fillText(line, this.margin, y);y += this.lineHeight;});// 绘制页码this.ctx.fillText(`Page ${pageIdx + 1}`, this.canvas.width - 60, this.canvas.height - 20);}clear() {this.ctx.clearRect(0, 0, this.canvas.width, this.canvas.height);}
}测试步骤：启动本地服务器：npx serve。
打开 index.html。
上传一个 TXT 文件。
观察翻页是否正确，长单词是否断行。常见问题：中文显示不全：Canvas 字体渲染有时会有亚像素问题，调整 lineHeight 为 fontSize * 1.4 更稳妥。
内存泄漏：如果文本很大，logicalLines 数组会很大。优化方案：不要一次性断行所有行。只在渲染当前页时，动态断行。这叫惰性计算。优化扩展：从 Demo 到实战
面试时，能讲出优化点，才是高分关键。
1. 虚拟滚动（Virtual Scrolling）
如果文本有 1000 页，不要预生成所有分页数据。
只保留当前页和前后 2 页的数据。
翻页时，动态计算新页的内容。
这能极大降低内存占用。
2. 目录生成
TXT 没有元数据，目录怎么来？方案 A：按空行分段，每段首行作为标题。
方案 B：识别 # 开头的行（模仿 Markdown）。
方案 C：用户手动标记。面试时推荐方案 A，简单可行，符合 TXT 特性。
3. 字体大小调整
用户可能放大字体。
字体变了，每页行数就变了，分页必须重算。
关键点：分页算法要能快速重算。
如果数据量大，重算卡顿怎么办？Web Worker：把分页计算放到后台线程，不阻塞 UI。
增量更新：只重算受影响的页面。4. 跨平台差异Web：Canvas 渲染。
移动端：可能用 WebView + JS 计算，原生绘制。
桌面端：Electron，可以直接用 node-canvas 或 Skia。面试加分项：
提到 Skia 引擎。
Chrome 和 Android 都用 Skia 渲染文本。
如果你说“我参考了 Skia 的文本布局逻辑，简化实现了 Kerning（字距调整）”，面试官会眼前一亮。
即使你没实现，也要知道有这个概念。
小结与面试话术
回顾一下，我们手写了一个“我爱电子书”的核心：解析：统一换行，切分文本。
分页：贪心断行，计算页码。
渲染：Canvas 绘制，惰性加载。面试时怎么答？“我之前做过一个实战项目，手写电子书阅读器。
核心难点是分页算法。
我实现了贪心断行策略，处理了长单词和中文换行。
为了性能，我引入了惰性计算，只渲染可视区域。
参考了 W3C 文本规范，但做了简化，保证面试现场能讲清楚原理。
如果继续扩展，我会用 Web Worker 优化计算，用 Skia 思路优化渲染。”这段话的亮点：有具体项目。
有算法细节（贪心断行）。
有性能意识（惰性计算、Web Worker）。
有行业认知（W3C、Skia）。
不吹牛，承认简化，体现务实。最后提醒：
别死记代码。
要理解为什么这样设计。
比如，为什么不用 DOM 而用 Canvas？
答：DOM 重排重绘成本高，文本量大时卡顿。Canvas 直接绘图，性能更可控。
你公司项目里是怎么处理大文本渲染的？是用 Canvas、WebGL 还是原生？
或者你们有没有遇到过字体渲染跨平台不一致的问题？
欢迎评论，一起交流。
3个核心算法手写我爱电子书解析，告别面试卡壳
3个核心算法手写我爱电子书解析，告别面试卡壳
面试官问：“如果让你从零手爱一个电子书阅读器，核心数据结构怎么设计？内存怎么控制？”
你心里慌了：平时只看过源码，没真正写过。
实战项目里，光会调用库没用，得懂底层。
项目目标与需求拆解
别被“电子书”三个字吓住。
对于应届生来说，核心不是做UI，而是处理文本流、分页渲染和状态同步。
我们要实现一个最小可用版本（MVP），支持 TXT 格式解析、分页显示、目录跳转。
这能覆盖 80% 的底层逻辑面试考点。
为什么选 TXT？
PDF 涉及字体渲染、矢量图形，太复杂。
TXT 是纯文本，逻辑清晰，适合手写核心算法。
官方文档中，W3C 标准对文本换行规则有明确定义，但手写时我们简化处理，只处理硬换行（\n）和软换行（宽度溢出）。
功能清单：解析器：读取文件，分块加载，避免一次性读入内存。
排版引擎：根据屏幕宽度，计算每页行数。
视图层：Canvas 或 DOM 渲染，这里用 Canvas 更贴近原生。
交互：上下翻页，目录树展开。避坑提醒：
很多初学者喜欢一开始就搞 Markdown 支持。
错。
先把纯文本跑通，再谈扩展。
贪多嚼不烂，面试时讲不清楚，反而扣分。
目录结构设计
好的目录结构，是代码可维护性的基石。
我们采用模块化设计，职责单一。
ebook-reader/
├── index.html # 入口页面
├── main.js # 应用初始化
├── core/
│ ├── parser.js # 文本解析器
│ ├── paginator.js # 分页算法
│ └── renderer.js # Canvas 渲染器
├── utils/
│ ├── fileLoader.js # 文件异步加载
│ └── logger.js # 调试日志
└── styles.css # 基础样式核心模块说明：parser.js：负责将原始字符串转为结构化行数组。
paginator.js：输入行数组和页面高度，输出每页的行号范围。
renderer.js：根据行号范围，在 Canvas 上绘制文本。为什么这样分？
面试时，你能画出这个依赖图，说明你有架构思维。
所有模块通过接口交互，不直接操作 DOM 或文件。
这样方便单元测试，也方便后续替换渲染层（比如从 Canvas 换成 WebAssembly）。
细节注意：
utils/fileLoader.js 使用 fetch API 异步读取本地文件（需配合 HTTP 服务器）。
如果面试现场是纯前端环境，可以模拟 Promise 返回字符串。
核心代码实现：解析与分页
这是面试最容易被问倒的部分。
分页算法不是简单的 slice，要处理长行断行。
1. 文本解析器 (parser.js)
/*** 将文本内容解析为行数组* @param {string} content - 原始文本* @returns {Arraystring} - 行数组*/
export function parseText(content) {// 统一换行符，处理 \r\n, \r, \nconst normalized = content.replace(/\r\n?/g, '\n');// 分割为行const lines = normalized.split('\n');// 过滤空行？不，保留空行，用于段落间距计算// 这里返回原始行，排版时再处理return lines;
}逐行讲解：replace(/\r\n?/g, '\n')：Windows 用 \r\n，Mac 用 \r，Linux 用 \n。统一成 \n 是基础功。
split('\n')：得到数组，每个元素是一行文本。
关键点：不要在这里做断行。断行是排版引擎的事。解析器只管“切块”。2. 分页算法 (paginator.js)
这是难点。
假设屏幕高度 800px，行高 20px，页边距 50px。
每页可显示行数 = (800 - 50*2) / 20 = 35 行。
但如果有超长单词，一行放不下怎么办？
我们需要一个简单的贪心断行算法。
/*** 简单贪心断行算法* @param {string} text - 单行文本* @param {number} maxWidth - 最大像素宽度* @param {number} fontSize - 字体大小* @returns {Arraystring} - 断行后的子行*/
export function breakLine(text, maxWidth, fontSize) {// 简化：假设每个字符宽度等于 fontSize * 0.5// 实际项目中需用 Canvas measureTextconst charWidth = fontSize * 0.5;const maxChars = Math.floor(maxWidth / charWidth);if (text.length = maxChars) {return [text];}const result = [];let remaining = text;while (remaining.length maxChars) {// 找到最后一个空格，避免单词切断let cutPos = remaining.lastIndexOf(' ', maxChars);if (cutPos === -1 || cutPos maxChars * 0.5) {// 没找到合适空格，硬切断cutPos = maxChars;}result.push(remaining.substring(0, cutPos));remaining = remaining.substring(cutPos).trimStart();}if (remaining.length 0) {result.push(remaining);}return result;
}避坑指南：硬切断：如果没有空格，强行切断。中文没有空格，直接按字符数切。
性能：这个算法是 O(n)，对于长文本没问题。
面试话术：可以提一下，生产环境会用 Canvas.measureText 获取精确宽度，但手写时简化为估算，体现工程权衡。3. 分页主逻辑
/*** 计算分页* @param {Arraystring} lines - 解析后的行* @param {number} linesPerPage - 每页行数* @returns {ArrayArraynumber} - 每页包含的行号索引*/
export function paginate(lines, linesPerPage) {const pages = [];let currentLineIdx = 0;// 先对所有行进行断行处理，得到“逻辑行”const logicalLines = [];lines.forEach(line = {// 假设 fontSize=16, maxWidth=600const broken = breakLine(line, 600, 16);broken.forEach(bl = logicalLines.push(bl));});// 按逻辑行分页for (let i = 0; i logicalLines.length; i += linesPerPage) {const pageLines = logicalLines.slice(i, i + linesPerPage);// 这里简化，实际应记录原始行号以便目录跳转pages.push(pageLines);}return pages;
}注意：
上面代码为了演示清晰，做了简化。
实际项目中，paginate 应该返回 { startIndex, endIndex }，而不是直接返回文本，这样渲染器可以按需加载。
运行与测试：Canvas 渲染
代码写完了，得跑起来。
我们用一个简单的 Canvas 渲染器。
// renderer.js
export class CanvasRenderer {constructor(canvas) {this.canvas = canvas;this.ctx = canvas.getContext('2d');this.fontSize = 16;this.lineHeight = 20;this.margin = 50;}renderPage(pageLines, pageIdx) {this.clear();this.ctx.font = `${this.fontSize}px sans-serif`;this.ctx.fillStyle = '#333';let y = this.margin;pageLines.forEach((line, index) = {// 绘制每行文本this.ctx.fillText(line, this.margin, y);y += this.lineHeight;});// 绘制页码this.ctx.fillText(`Page ${pageIdx + 1}`, this.canvas.width - 60, this.canvas.height - 20);}clear() {this.ctx.clearRect(0, 0, this.canvas.width, this.canvas.height);}
}测试步骤：启动本地服务器：npx serve。
打开 index.html。
上传一个 TXT 文件。
观察翻页是否正确，长单词是否断行。常见问题：中文显示不全：Canvas 字体渲染有时会有亚像素问题，调整 lineHeight 为 fontSize * 1.4 更稳妥。
内存泄漏：如果文本很大，logicalLines 数组会很大。优化方案：不要一次性断行所有行。只在渲染当前页时，动态断行。这叫惰性计算。优化扩展：从 Demo 到实战
面试时，能讲出优化点，才是高分关键。
1. 虚拟滚动（Virtual Scrolling）
如果文本有 1000 页，不要预生成所有分页数据。
只保留当前页和前后 2 页的数据。
翻页时，动态计算新页的内容。
这能极大降低内存占用。
2. 目录生成
TXT 没有元数据，目录怎么来？方案 A：按空行分段，每段首行作为标题。
方案 B：识别 # 开头的行（模仿 Markdown）。
方案 C：用户手动标记。面试时推荐方案 A，简单可行，符合 TXT 特性。
3. 字体大小调整
用户可能放大字体。
字体变了，每页行数就变了，分页必须重算。
关键点：分页算法要能快速重算。
如果数据量大，重算卡顿怎么办？Web Worker：把分页计算放到后台线程，不阻塞 UI。
增量更新：只重算受影响的页面。4. 跨平台差异Web：Canvas 渲染。
移动端：可能用 WebView + JS 计算，原生绘制。
桌面端：Electron，可以直接用 node-canvas 或 Skia。面试加分项：
提到 Skia 引擎。
Chrome 和 Android 都用 Skia 渲染文本。
如果你说“我参考了 Skia 的文本布局逻辑，简化实现了 Kerning（字距调整）”，面试官会眼前一亮。
即使你没实现，也要知道有这个概念。
小结与面试话术
回顾一下，我们手写了一个“我爱电子书”的核心：解析：统一换行，切分文本。
分页：贪心断行，计算页码。
渲染：Canvas 绘制，惰性加载。面试时怎么答？“我之前做过一个实战项目，手写电子书阅读器。
核心难点是分页算法。
我实现了贪心断行策略，处理了长单词和中文换行。
为了性能，我引入了惰性计算，只渲染可视区域。
参考了 W3C 文本规范，但做了简化，保证面试现场能讲清楚原理。
如果继续扩展，我会用 Web Worker 优化计算，用 Skia 思路优化渲染。”这段话的亮点：有具体项目。
有算法细节（贪心断行）。
有性能意识（惰性计算、Web Worker）。
有行业认知（W3C、Skia）。
不吹牛，承认简化，体现务实。最后提醒：
别死记代码。
要理解为什么这样设计。
比如，为什么不用 DOM 而用 Canvas？
答：DOM 重排重绘成本高，文本量大时卡顿。Canvas 直接绘图，性能更可控。
你公司项目里是怎么处理大文本渲染的？是用 Canvas、WebGL 还是原生？
或者你们有没有遇到过字体渲染跨平台不一致的问题？
欢迎评论，一起交流。