简介《手稿》Manuscript是一份与字体设计相关的RAR压缩资源面向需要手写风格字体的平面设计师、文档排版人员及个人创作者用于解决正文或标题中营造自然手写质感的问题。包内共3个文件包含TTF字体文件、GIF格式的字体效果预览图以及一份HTM格式的说明文档整体体积仅45KB小巧易下载适合快速试用手稿体并了解其应用场景。资源目前已有293人学习说明其在字体下载与排版应用方面具备一定参考价值。解压后用户可直接安装TTF字体通过预览图直观查看字形风格并依据说明文档的提示在Word、Photoshop等软件中调用该字体适合需要为个人笔记、海报标题或创意文案增加手写温度的轻量设计需求。1. Manuscript 在科研工作流里到底是什么一个比“写稿”大得多的工程问题如果只看字面意思Manuscript 就是“手稿”很多刚从 Word 切换到学术写作的研究者会以为它指某个写作软件或模板。但当你真正蹲在一个项目的输出阶段——实验做完了、图表画好了、剩下的是把 60 页内容整理成一篇能投出去的论文——你会发现“手稿”两个字被严重低估了。它其实涵盖了从 Markdown 写作草稿、LaTeX 源码、参考文献库到编译脚本、图表文件、版本历史、投稿格式定制这一整条生产线。我见过某实验室的 A 同学论文返修时因为找不到上一版图表的源文件硬是在最终 PDF 里截了一张低分辨率图贴回去差点被审稿人打回。Manuscript 要解决的正是这种混乱把一篇论文从草稿到定稿之间的版本管理、格式转换、编译排错、引用同步全部收口到可复现的工作流里。我们团队现在跑一个模拟项目 X 的时候内部的写作规范就是“所有正式输出都从 Manuscript 流程走”。这套流程的核心不是某个软件而是一套约定纯文本源文件、统一目录结构、脚本化编译、Git 版本控制。这篇文章我会把从零搭起这套手稿生产线的步骤、必调参数和踩过的坑全部摊开讲。适合正在写毕业论文、准备投稿、或维护多篇在写论文的人新手能照着命令跑通熟手可以重点看格式转换和避坑部分。2. 从无到有搭手稿生产线为什么选型的顺序决定后面少走多少弯路2.1 先想清楚“手稿”要管哪些事再谈工具选型动手写第一篇论文时我犯过一个典型错误一上来就在网上找模板模板套进去后开始写写到第三章发现图表编号全乱参考文献格式不对想换模板又怕字全没了。后来我复盘为什么 Word 写论文总是越改越乱的根源——Word 把内容、样式、排版、版本这四件事揉在一起任何一处的改动都会牵连其他三处。而 Manuscript 思路的第一步就是把这些职责拆开内容放纯文本样式交给模板排版交给编译引擎版本交给 Git。具体到一篇学术手稿你需要管理的资产通常包括正文源文件、图表文件矢量图源文件和导出文件都要留、参考文献库BibTeX 或 CSL 格式、编译脚本、投稿所需的元数据作者、摘要、关键词、以及每一轮的修改记录。选型前先用一张表把这七类资产列下来比先选编辑器靠谱得多。我当时是拿 OneNote 先把这些列出来再决定用什么工具整个过程两小时但后面写稿时几乎没有因为“找不到某样东西”而中断过。我的常规选型是正文用 Markdown 写初稿、用 Pandoc 转 LaTeX 出最终 PDF如果需要出版社强制 LaTeX 模板就纯 LaTeX 写参考文献统一用 BibTeX 管理图表用 draw.io 和 matplotlib 出矢量格式版本管理用 Git。这套组合的好处是每一步的工具都足够“傻”坏了你知道去哪修而不是打开一个黑匣子无从下手。2.2 目录结构和初始化命令给手稿修一条“不会乱”的管道选型定下来后第一件事是搭目录骨架。我见过太多人把论文源文件、图表、参考文献、旧版本全堆在一个文件夹里最后编译时引用路径一塌糊涂。一个干净的手稿项目目录应该是这样的manuscript-demo/ ├── content/ # 正文源文件.md 或 .tex │ ├── 00_abstract.md │ ├── 01_introduction.md │ ├── 02_method.md │ ├── 03_results.md │ └── 04_conclusion.md ├── figures/ # 图表的源文件与导出文件 │ ├── src/ # draw.io / matplotlib 源文件 │ └── pdf/ # 最终引用 PDF 版本 ├── references/ # BibTeX 库 │ └── refs.bib ├── templates/ # 期刊模板 / 自定义样式 ├── scripts/ # 编译脚本、转换脚本 ├── output/ # 生成的中间文件和最终 PDF └── archive/ # 历史版本快照这个结构的核心思想内容、资源、产物三分开。output/目录下的任何文件都可以随时删除重新生成因为真正的源文件在另外三个目录里。真正动手创建时我习惯写一个初始化脚本而不是手动mkdir这样多台机器、多个项目可以保持完全一致的结构#!/bin/bash # 初始化一个 Manuscript 项目骨架 # 用法: ./init_manuscript.sh project_name set -e # 任何一步出错就停止避免半成品目录 PROJECT_NAME${1:-my_manuscript} mkdir -p $PROJECT_NAME/{content,figures/src,figures/pdf,references,templates,scripts,output,archive} touch $PROJECT_NAME/README.md touch $PROJECT_NAME/content/00_abstract.md touch $PROJECT_NAME/references/refs.bib echo # $PROJECT_NAME $PROJECT_NAME/README.md echo Project skeleton created at $PROJECT_NAME这段脚本有三个值得注意的参数。set -e很关键——如果中途磁盘空间不足或目录已存在导致mkdir报错脚本会立即退出不会留下一个缺了output/的残缺项目。${1:-my_manuscript}的意思是传了第一个参数就用它做项目名没传就用my_manuscript兜底。最后touch空文件和echo写入 README 是为了让 Git 能跟踪空目录——Git 本身不跟踪目录只跟踪文件。创建完目录后我建议立刻执行git init并做第一次提交。这一步看似多此一举但它的作用是给整个项目打第一个“后悔药”锚点。我一开始没做写了两周稿子后才想起建仓库结果无法区分哪次大改对应哪个实验版本只能靠文件名里的v2_final_真final硬扛那种体验经历过一次就不想再来第二次。2.3 写作源文件选 Markdown 还是 LaTeX别装按场景切Markdown 和 LaTeX 之争是手稿工作流里最没必要的争论。我的判断标准非常简单团队协作和快速迭代时优先 Markdown单作者定稿或出版社有硬性模板要求时直接 LaTeX。Markdown 写的草稿任何人打开都能读能改diff 的时候干净到可怕LaTeX 则是在你明确知道最终要两栏排版、要公式编号、要浮动体位置严格受控时省去 Pandoc 中间层直接一步到位。我经历过一个翻车现场某投出去的期刊要求 Word 稿但图表必须是矢量图我们用 Pandoc 从 Markdown 生成 docx结果图全插入成功了但公式全部变成了 OMML 对象审稿人反馈某些符号渲染不对。后来排查发现是 Pandoc 的--mathml参数没加对用--webtex老接口生成的是图片公式放大就糊。从那以后我的习惯是目标格式是 docx 就用 Pandoc 的 RTF/MathML 链路目标格式是 PDF 就直接走 LaTeX不硬让 Pandoc 扛所有转换。但选 Markdown 还是 LaTeX 不是二选一。很多手稿项目是混合的——正文用 Markdown 写快速内容图表用 LaTeX TikZ 画最终用 Pandoc 拼装。这个组合适合方法部分包含大量公式和图但叙述部分又需要频繁修改的场景。关键是把 Markdown 作为“母本”LaTeX 作为“产物之一”你自己决定什么时候把母本冻结掉转成 LaTeX 做最终排版。我在内部项目 X 里就规定内容冻结前别碰 LaTeX冻结后再开revision/分支去做模板适配这样写作和排版两个阶段的焦虑不会互相污染。3. 用 Git 和 Makefile 让 Manuscript 从头到尾“一键可复现”3.1 版本管理与分支策略把每一轮返修变成可回滚的提交手稿的版本管理和代码有一个显著不同代码的“编译”是跑起来看逻辑对不对手稿的“编译”是生成 PDF 看排版和内容对不对。因为最终读者看到的是 PDF所以 Manuscript 的版本策略必须保证任何一次编译都能对应到一组明确的源文件。我的实践是main分支永远对应当前可提交的版本dev分支存放未完成的内容archive/目录存放历史快照的 PDF 和源文件。具体操作上每完成一轮修改就提交一次提交信息按“动词对象”的格式写例如feat: add ablation study table或fix: correct equation 3 notation。我自己不强制写什么规范但要求必须写上“为什么改”而不是“更新了内容”。三个月后回来看提交历史你能直接说清每一次改动的动机而不是靠猜。# 初始化仓库并设置用户Mac/Linux 都适用 git init git config user.name Your Name git config user.email youexample.com # 创建主分支和开发分支 git checkout -b main git checkout -b dev # 日常流程改完内容后走“提交-合并”小步快跑 git add content/ figures/references/refs.bib git commit -m fix: correct equation 3 notation git checkout main git merge dev --no-ff -m merge dev: equation fix.gitignore必须把output/和可能的*.aux*.log*.synctex.gz排掉这些编译中间文件会让仓库急速膨胀。.gitignore文件本身我放在项目根目录内容至少包含这三类output/、编译残留、还有编辑器缓存.DS_Store、.vscode/。因为图表源文件如果动不动几十 MB我会用 Git LFS 去管而不是硬塞进普通仓库不然克隆一次仓库要喝一杯咖啡。3.2 Makefile 统一编译入口把 Pandoc、LaTeX、BibTeX 串成一条链当手稿包含多文件时手动敲 Pandoc 加 xelatex 命令是效率杀手而且容易漏步骤。BibTeX 尤其折磨人——每次改引文后必须“xelatex → bibtex → xelatex → xelatex”跑两遍以上漏一遍引用编号就变成问号。Makefile 可以把这串动作固化下来让编译变成零思考的执行# 手稿编译配置 MD_FILES : content/00_abstract.md content/01_introduction.md \ content/02_method.md content/03_results.md content/04_conclusion.md BIB_FILE : references/refs.bib TEX_FILE : output/manuscript.tex PDF_FILE : output/manuscript.pdf # 目标最终 PDF $(PDF_FILE): $(MD_FILES) $(BIB_FILE) templates/ieee.csl pandoc $(MD_FILES) \ --from markdown \ --to beamerlatex \ --citeproc \ --bibliography$(BIB_FILE) \ --csltemplates/ieee.csl \ --output$(TEX_FILE) 21 xelatex -interactionnonstopmode -halt-on-error \ -output-directoryoutput \ $(TEX_FILE) 21 bibtex output/manuscript.aux 21 || true xelatex -interactionnonstopmode -halt-on-error \ -output-directoryoutput \ $(TEX_FILE) 21 xelatex -interactionnonstopmode -halt-on-error \ -output-directoryoutput \ $(TEX_FILE) 21 # 清理编译中间文件 clean: rm -rf output/*.aux output/*.bbl output/*.blg \ output/*.log output/*.out output/*.synctex.gz .PHONY: clean这个 Makefile 有四个参数需要你按自己项目改MD_FILES是正文文件的顺序列表注意目录顺序就是最终论文的章节顺序BIB_FILE指向 bib 库--csl指定参考文献样式用期刊的官方 CSL 替换ieee.csl-interactionnonstopmode -halt-on-error是 LaTeX 的黄金组合——前者让编译不因警告停下后者确保真错误立刻退出而不是生成一个半残 PDF 让你误以为成功了。如果你觉得xelatex每次都跑四遍浪费可以用latexmk替代它内置了依赖跟踪和重跑逻辑。我在大型手稿项目——比如 15 章以上的毕业论文——用latexmk -pdf -xelatex -interactionnonstopmode output/manuscript.tex一行搞定。但小文章我反而用显式四连因为你能清楚看到每一步卡的哪个环节排错更直白。3.3 内容冻结与变更流程防止“改着改着忘了原文长啥样”手稿的第二次大坑是“内容反复横跳”——昨天删掉的段落今天又想加回来但删之前没保存。为这个我尝过失而复得的甜头也吃过找不回来的苦。现在规矩是任何整段删除或大重构之前先在archive/里存一份当前版本的 PDF 和源文件快照然后才开始动刀。快照含义是冻结某个时间点的内容不是每天备份。我在项目里用一个简单脚本snapshot.sh归档当前状态。它本质上就是复制源文件到带时间戳的目录然后提交一次 Git。执行时间两秒但心理收益巨大——你不再怕改坏因为总有最后一个干净的分岔口可以回去。另一个细节图表源文件、参考文献和正文快照必须同时归档缺一个三个月后的你看到旧 PDF 也只能干瞪眼。通常的节奏是每周五下午做一次快照同时清理掉archive/里超过三个月的中间版本只留关键节点。这样归档目录不会膨胀到几百个文件夹找东西也不用翻历史目录。4. 格式转换与交叉引用的硬骨头Pandoc 模板、引用与图表的四类坑4.1 Pandoc 模板定制从 Markdown 到 LaTeX 的“最后一公里”Pandoc 默认生成的 LaTeX 是通用版式直接投稿会被期刊模板打回。它的解法是--template参数但大部分人的误区是“找个期刊模板把内容塞进去”。正确的是Pandoc 模板是你和期刊模板之间的粘合层它负责把你的元数据和 Markdown 内容填充到期刊模板需要的位置。我先解释机制。Pandoc 的默认 LaTeX 模板里有一组变量比如$title$、$author$、$date$、$if(abstract)$你把 Markdown 的 YAML 头注按这些变量名填生成时就能自动对齐。但期刊模板往往不叫title而叫\title或\journaltitle所以你要在自定义模板里做映射把$title$映射成期刊要求的命令。--- title: On the Efficiency of Manuscript Pipelines author: - name: 某开发者 affiliation: 某实验室 email: devexample.com date: 2025-01-15 abstract: 本文提出一套可复现的手稿生产...省略 keywords: [manuscript, pandoc, latex] ---生成的 LaTeX 里这些 YAML 字段会被填到模板变量位。我用 Pandoc 的--template参数时习惯先生成一份默认模板看变量结构# 导出 Pandoc 默认 LaTeX 模板 pandoc -D latex my_template.tex # 用自定义模板生成 LaTeX 源文件 pandoc manuscript.md \ --templatemy_template.tex \ --from markdownyaml_metadata_block \ --to latex \ --outputoutput/manuscript.tex关键的参数是--from markdownyaml_metadata_block。如果你不加这个扩展Pandoc 会把 YAML 头注当普通文本标题就会以奇怪的方式出现在正文里。我第一次就栽在这里生成的 PDF 第一页顶部赫然印着---整个心情都崩了。4.2 图表跨目录引用路径问题的玄学与正解手稿项目里图表放在figures/pdf/正文在content/LaTeX 的\includegraphics路径默认是相对编译目录的。我的 Makefile 让xelatex从output/目录运行于是figures/路径就全断了。Pandoc 转出来的 LaTeX 里图片路径是按 Markdown 里的相对路径写的在output/里自然找不到../figures/pdf/figure1.pdf。标准解法是终极处理器里加一层路径映射要么给\graphicspath{../figures/pdf/}指令要么给 Pandoc 加--resource-path参数让它能找到资源文件。但这里有个隐藏坑--resource-path只影响 Pandoc 读取 Markdown 中的图片不影响 LaTeX 内的\includegraphics。换句话说你要在两条链路里同时让路径正确。pandoc manuscript.md \ --resource-path.:figures \ --outputoutput/manuscript.tex同时在生成的manuscript.tex开头或模板里加上\graphicspath{{figures/pdf/}}。如果你嫌麻烦更稳的方案是在content/里写相对路径../figures/pdf/xxx.pdfPandoc 生成时直接保留LaTeX 在output/下编译时用\graphicspath{{../figures/}}把根目录指到正确位置。这种方式绕开了所有玄学路径报错。4.3 参考文献与交叉引用为什么会双倍编译以及--citeproc的陷阱手稿的参考文献有两条链路Pandoc 的--citeproc把 Markdown 中的[doe2020]直接解析成格式化引用条目这适合快速生成 Word 或轻量 PDF但如果你要转 LaTeX 再用 BibTeX 管理就绝不能开--citeproc因为 Pandoc 会把引用文本直接变成静态字符串BibTeX 再跑一遍会 “double-format”——你的引用编号变成[12]12这种重叠样式。正确做法在 Markdown 里写裸引用键doe2020Pandoc 只负责把它转成\cite{doe2020}不要加--citeproc然后让 BibTeX 统一处理格式。记得在 Markdown 里把需要交叉引用的公式或章节用{#eq:sample}打上标记Pandoc 转成 LaTeX 时自动对应\label{eq:sample}和\ref{eq:sample}。这样你的引用链路是纯 LaTeX 的逻辑完全可控。如公式 eq:mse 所示均方误差定义为... $$ MSE \frac{1}{n}\sum_{i1}^n (y_i - \hat{y}_i)^2 $$ {#eq:mse}Pandoc 生成后LaTeX 里就是\eqref{eq:mse}BibTeX 和交叉引用互相独立、互不干扰。这个选择牺牲了一部分 Pandoc 的一键省事但换来了投稿前的确定性——你不会在最后一刻发现引用编号是 Pandoc 写的、期刊模板不认。4.4 数学公式与字体嵌入PDF 交付前必须做的一次体检用xelatex编译时中文字体嵌入是另一个容易爆雷的点。默认的 LaTeX 字体引擎不会自动处理中文你的 PDF 会出现空白、方块或字体重叠。我的模板里固定用ctex文档类配合fontsetfandol这样不需要系统预装任何中文字体Linux 和 macOS 都能编译通过\documentclass[fontsetfandol, 12pt]{ctexart}字体嵌入的体检方法生成 PDF 后用pdffonts命令检字体列表如果看到某字体显示no embed或语法有subset的百分比不足说明某些字符可能用错了字体投稿系统很可能拒收。这步不是可有可无的洁癖某次我按标准流程提交手稿编辑部反馈 PDF 内嵌字体不合规直接被退回修改后来就再不敢跳过体检。5. Manuscript 常见踩坑指南五个“现象 → 原因 → 解决”的血泪账5.1 Pandoc 转换时报unexpected symbol near 现象pandoc manuscript.md -o output.tex时终端直接弹unexpected symbol near 或生成的.tex文件里全是奇怪的 HTML 标签。原因这个报错九成是因为 Markdown 的 YAML 头注里---和标题之间缺了空行或头注里的某个字段值包含了未转义的字符Pandoc 误以为你写了 HTML 代码块。还有一成因是 Markdown 文件用了 CRLF 换行符Pandoc 解析器在跨平台时会抽风。解决先检查 Markdown 文件开头是否有干净的三段式结构---空行 字段 空行---。其次用file manuscript.md查看换行符如果是 CRLF用sed -i s/\r$// manuscript.md转成 LF重新编译。我一般还会在 Makefile 里加一个lint目标用pandoc -f markdown -t native manuscript.md预解析能提前暴露语法问题。5.2 BibTeX 编译后所有引用变成?问号现象跑完bibtex manuscript.aux后PDF 里所有\cite位置都是一个粗体问号参考文献列表空白。原因bib 库路径没对上或 BibTeX 找不到.aux文件的位置。Makefile 里我写的是bibtex output/manuscript.aux但 BibTeX 在output/之外运行时默认去当前目录找.aux如果当前目录没有它就什么都不干直接报“I couldnt open file”。解决进到output/目录再跑 BibTeX或者用-include-directoryoutput参数。我最后的做法是压根不手动跑在 Makefile 的clean目标里删掉.aux.bbl.blg然后让latexmk自动调度 BibTeX 运行顺序人只负责输入make。5.3 图表正确但 PDF 里的图全部错位或消失现象Pandoc 正常生成 LaTeXPandoc 日志也输出 “Fig 1 processed”但最终的 PDF 里没有图或图表跳到了完全不相关的章节。原因最常见的根因是\includegraphics里的路径末端缺少默认扩展名。如果你的图片是figure1.pdf但 Markdown 里写的是figure1.png的引用Pandoc 不会自动帮你改扩展名生成的 LaTeX 就指了一个不存在的路径。另外LaTeX 的浮动体位置参数[htbp]没加图会被推到最后几页。解决给 Pandoc 传图片时确认扩展名正确并在 Markdown 里明确.pdf后缀。浮动体位置问题在模板里统一加\floatplacement{figure}{H}强制就地放置。这种方法对页面拥挤的论文不友好但它能让你快速定位是哪一张图断链而不是整篇 PDF 末尾冒一堆孤儿图。5.4 参考文献样式和期刊要求的[1]差一点现象引用编号格式对但作者名大小写、期刊缩写、页码格式有一项和期刊指南不一致投稿系统反馈“formatting not compliant”。原因你的 CSR 或 BST 文件和期刊要求有细微差别。Pandoc 的--citeproc能输出 APA/Chicago 等常见样式但很多期刊有自己的定制 CSL出发点是从官方给出的样式文件手动改成你要的格式。解决去期刊官网下他们的 CSL 文件放到templates/下并固定引用。如果是自定义 BibTeX BST没关系用\bibliographystyle{unsrtnat}和natbib宏包重排再对着期刊指南逐条核对作者名缩写、期刊名缩写规则。这个核对虽然枯燥但它是提交前唯一的保险。5.5 LaTeX 编译卡死或内存不足现象xelatex在中途挂起不退出或报! Emergency stop终端日志最后几行是main_memory相关字样。原因手稿中文档类、宏包和超链接组合导致 TeX 内存不足更常见的是图片数量巨大且分辨率超高每个 PDF 图几 MBLaTeX 排版时反复做边界盒计算直接压爆默认内存上限。还有一个隐蔽源是\includegraphics反复加载同一张量大图而没有用\includegraphics的trim参数裁剪空白。解决在xelatex调用前设置环境变量ulimit -v不是正道。正确做法是在模板的\documentclass后加几行\usepackage{etex}提升内存管理并给\includegraphics统一加\graphicspath{}和\DeclareGraphicsExtensions{}限制扫描范围。如果图实在太多把矢量图导入时先导出成压缩后的 PDF 版本一张图控制在 500KB 以内编译速度能快一倍。6. 进阶技巧给 Manuscript 上自动化体检、批量旧稿回收与自定义模板组装到这一步你的 Manuscript 工作流已经能稳定生成 PDF 了。进阶的目标是把它变成“少盯着也能跑”的产线。我会用两个手段第一在 Makefile 的lint目标里加入拼写检查、引用完整性和图表路径验证第二用 Git 的 pre-commit 钩子跑一次 Pandoc 预转换确保每次提交的源文件都可编译。lint: pandoc -f markdown -t native $(MD_FILES) /dev/null 21 echo MD syntax OK python3 scripts/check_citations.py $(MD_FILES) references/refs.bib python3 scripts/check_figures.py content/ figures/check_citations.py的逻辑很简单扫描 Markdown 里的[key]引用对照refs.bib里是否存在key。check_figures.py解析 Markdown 中的![]()路径逐个os.path.exists()检查文件是否真实存在于figures/下。这两段脚本加起来不到六十行但它们把“手稿能不能编译”从手动玄学验证变成了每次提交前的自动闸门。批量旧稿回收是我处理历史遗留问题的常用手段。某同事手上有二十多篇 Word 版毕业论文想统一改成 LaTeX 工作流我建议的做法是解析 Word 转 Markdown 时只用 Pandoc 的一次性转换并小心处理 Word 中的表格、交叉引用和多级编号。注意转换后不要直接编译 PDF而是要先进 Our 目录结构把 Word 内容按章拆成多个.md文件手动核对公式和插图路径后再走正式流程。这个验证步骤不能跳因为 Pandoc 的 docx 解析器对样式复杂的 Word 文件依然脆弱跳过了后面排错成本更高。组装自定义模板是我最后想强调的经验。我维护了一套journal_template.tex它包含一个简单的「输入是 Markdown、输出符合期刊要求 PDF」的完整模板字段包括期刊名、投稿编号、版权行、DOI 等。替换模板里对应的宏包和参数就能适配不同期刊。我自己的习惯是三个月迭代一次模板每投一次期刊就吸收一次它的样式细节到维护的模板里而不是每次从头写。这个习惯坚持下来一个模拟项目 X 的返修三审只需要改三行模板变量不用动正文任何内容。最后说句实在的Manuscript 这套流程的精髓不是某个命令或某段脚本而是“源文件唯一可编译、产物可复现、历史可追溯”这三个习惯。你可以不照搬我的目录结构但你至少要给自己定一条规矩——任何投出去的版本都必须在三个月后还能完美重编译。这条规矩救过我一次返修审稿人要求补两幅实验对比图我用归档快照二十分钟找回了实验参数和图表源文件第二天就把修改稿交出去了。如果你现在手里还有一篇用v2_final_最终版命名法在管理的论文不妨从今天开始把它迁移进这套手稿流程第一周可能会慢但一个月后你会感谢当初这个决定。希望帮到你。本文还有配套的精品资源点击获取