简介：LibreCAD是一款基于Qt框架、采用C++ 11开发的跨平台开源2D CAD程序，支持Windows、Linux与macOS，能够读取DXF和DWG文件，并导出DXF、PDF、SVG等格式，可满足机械制图、建筑平面、工程绘图等各类二维设计需求，适合初学者、工程师及企业用户使用。该资源以zip压缩包形式提供，整体大小约16.46MB，便于快速下载部署；上游未提供包内文件清单，具体文件构成需以解压后的实际内容为准。目前已有2767人学习，具有一定参考热度。软件界面高度可定制，提供数十种语言翻译，内置精确绘图、测量、实体编辑、图层管理、3D视图、块和外部参照等专业工具，并支持LISP脚本扩展，方便用户编写宏或插件以提升效率。开源社区活跃，持续迭代更新，对希望免费获得强大二维CAD能力的用户来说，是一份值得收藏的实用资源。

1. LibreCAD 是谁：一个能读 DWG、免费跨平台的 Qt 2D CAD，到底能替你做什么

上周同事拿过来一个 DWG 图纸，电脑上没装商业 CAD，客户发来的文件还带十几层图层。我用 LibreCAD 打开，图层全在、尺寸能查，还能直接导出 PDF 发给供应商。这就是 LibreCAD 最典型的价值：一个基于 Qt 框架和 C++11 写成、能读取 DXF 和 DWG、也能写出 DXF/PDF/SVG 的跨平台 2D CAD 程序，界面高度可定制，内置几十种翻译。它不是要替代重型 CAD 软件，而是充当看图、审图、格式互转与自动化管线的中间层。适合谁？没有预算买商业授权的中小团队、需要快速核对图纸的现场工程师，以及想在自己工具链里集成 DXF 处理的开发者。

2. 先算架构账：Qt 框架和 C++11 决定了 LibreCAD 的上限与边界

2.1 Qt 框架和 C++11 对使用者的三个直接影响

LibreCAD 是跨平台程序，Windows、Linux、macOS 三端共用同一套代码，UI 层用的是 Qt 的经典 Widget 体系，绘图区由 QPainter 承担。这一点决定了它的关键特性：同一份 DXF 文件，你在三套系统里打开，几何位置和图层关系是高度一致的，因为解析和渲染逻辑在同一份 C++ 代码里。但字体渲染、PDF 导出时的嵌入字形、打印驱动的边距处理，仍然跟着操作系统走，所以不要指望不同系统导出的 PDF 逐像素相同。

第二个影响是扩展方式。C++11 意味着代码库是现代 C++ 风格，而不是老掉牙的 C 风格，这对想改代码的人非常友好。工程用 CMake 组织，依赖 Qt 库，想二次开发的人只要有 C++ 和 Qt 基础就行，不需要先啃一套私有脚本语言。LibreCAD 没有提供插件 SDK，所有深度定制都落在“改源码、自己编译”这条路上。

第三个影响是性能墙。LibreCAD 的绘制不走 GPU 管线，重绘大量实体时主要靠 CPU，缩放和平移大图纸会明显感到吃力。这一点在使用上几乎每天都能遇到，后面避坑章节我会单独展开。理解这三点，你就知道哪些问题可以怪软件、哪些问题是机制使然、哪些问题只能靠工作流设计绕过去。

2.2 打开 DXG 和 DWG 为什么是两套命运

DXF 是公开的交换格式，ASCII 或二进制，由成对的组码构成，LibreCAD 对它的解析非常彻底。日常工作中我几乎把所有“要到别的软件里继续编辑”的图纸都转成 DXF，就是因为这条链路最可靠。

DWG 则是另一回事。它是私有闭源格式，LibreCAD 依赖底层读取库去识别其中的实体和表数据，能做到“打开并且大致正确”，但并不能覆盖所有版本的所有实体类型。常见丢东西的场景包括：较新版本 DWG 里的自定义对象、代理实体、带有厂商扩展数据的块。如果你拿到的 DWG 是某个垂直行业插件生成的，LibreCAD 打开后缺实体是正常现象，不是 Bug。

实操时我的原则很简单：DWG 只用于临时看图；只要后续还要做格式转换或出图，就先让来源方用上游软件另存为 DXF，或自己在 LibreCAD 里另存为 DXF 后认真核对一遍差异。把 DXF 当成桥梁、把 DWG 当成一次性消耗品，能少踩一半坑。

2.3 导出 PDF 和 SVG，本质是一次重新绘制

很多人误以为导出 PDF 是“把 DXF 数据搬进 PDF 容器”，其实不是。LibreCAD 的导出走的是打印管线：它先把当前文档里所有可见实体用 QPainter 重新画一遍，再把绘制结果交给 PDF 或 SVG 写出。这就解释了三个常见现象：

一是图层被隐藏的实体不会出现在导出文件里，这符合直觉。二是线宽和颜色会受当前显示的线宽模式影响，屏幕上看起来是细线，导出后可能变成粗线，因为打印管线有自己的线宽映射。三是文字和线型在导出时会再次走系统字体匹配，屏幕上正常的文字导出后可能变方框。理解了导出是一次重绘，排查导出问题就不再是玄学，而是去检查显示状态、字体映射和线宽设置这三处。

3. 把 DWG、DXF、PDF、SVG 串成一条可复用的文件流水线

3.1 开箱即用的最短路径：用 LibreCAD 把 DWG 转成可编辑的 DXF

最常见的需求是把收到的 DWG 变成能继续编辑的 DXF。打开 LibreCAD，文件菜单里选择打开，定位到 .dwg 文件，程序会尝试读取并显示。接着用“另存为”，把保存类型选为 DXF，弹出对话框里一般会有格式版本和编码方式的选择。我的习惯是选 ASCII 编码，不要选二进制，因为二进制 DXF 在某些下游程序里读取兼容性反而差。

版本选项上，优先选一个“老牌通用”的版本，2000 之后早一点的版本往往最好用，太新的版本对方软件不认，太老的版本会丢掉图层属性。保存完之后不要直接发出去，用下面这段脚本快速普查一下文本实体有没有在转换中丢失：

import dxfgrabber dxf = dxfgrabber.readfile("转换结果.dxf") texts = [e for e in dxf.modelspace() if hasattr(e, "text")] print(f"文本实体共 {len(texts)} 条") if texts: print(f"第一段文本内容：{texts[0].text}") else: print("警告：转换结果里没有任何文本实体")

这段代码用 dxfgrabber 打开转换后的 DXF，遍历模型空间，把带 text 属性的实体视为文本或多行文字。逻辑上先数数量，再抽一段内容做样例，用来判断 DWG 转 DXF 过程中文字是否大面积丢失。如果你发现源文件里明明有标注、转出来却是 0 条，说明读取阶段就已经丢了，这是 DWG 兼容问题，不是在 LibreCAD 里再转一次能解决的。

3.2 导出 PDF 和 SVG：六组设置与我的默认值

导出 PDF 走的是文件菜单里的打印或导出功能，真正决定成品质量的是对话框里的设置项，而不是图纸本身。下面这组参数是我在多个项目里反复试出来的起点值，你可以按自己下游需求调整：

SVG 导出的设置思路类似，但有一个额外注意点：SVG 是矢量格式，浏览器打开时如果没有显式设置背景色，透明背景在某些看图工具里会显示成黑底。我的习惯是导出 SVG 前把背景色改成白色再导出，避免对方收到文件后第一眼觉得图坏了。另外 SVG 里的线宽是数值属性，不是屏幕像素，缩放浏览器时不会失真，所以不要按屏幕显示比例去调线宽。

3.3 批量转换的现实路线：开源 CAD 没有银弹，但可以半自动

LibreCAD 没有提供面向批量的命令行导出接口，这是很多新用户第一次想“自动化”时撞到的墙。命令行拉起 LibreCAD 打开文件是可行的，但后续的导出动作仍然需要人工在界面里完成。常见做法是接受“脚本做前置处理，LibreCAD 做最终出图”的分工。我一般会先把所有待处理图纸生成一个带状态的清单，再逐个打开处理：

# 把工作目录下所有 dxf/dwg 生成一个带状态的处理清单 find ./图纸 -type f \( -name "*.dxf" -o -name "*.dwg" \) > 待处理清单.txt # 按文件行数排序，把体积大、结构复杂的排前面，先处理难点 wc -l 待处理清单.txt

这条命令的作用是把散落在子目录里的 CAD 文件收集成清单，再用 wc 看总数量。真正的导出动作还是要在 LibreCAD 里做，但有了清单，你至少不会遗漏文件。如果你要彻底自动化，只有两条路：一是用操作系统级别的界面自动化工具去模拟点击，但 LibreCAD 的对话框在不同版本里布局不一致，脚本很容易翻车；二是基于源码做二次开发，写一个只承担“读 DXF 写 PDF”的内部工具，工程量看你要支持多少种实体，不算小。

4. 把 LibreCAD 改成自己团队的软件：界面定制与多语言落地

4.1 不改代码的定制：工具栏、快捷键和配置文件

LibreCAD 的界面定制能力来自 Qt 的窗口体系，工具栏可以拖拽、可以增删按钮，快捷键可以在设置里改，命令行面板可以打开或收起。这些配置不需要改代码，程序会写入用户配置目录下的文本配置文件里，Windows 一般在当前用户的 AppData 下，Linux 和 macOS 一般在用户主目录的 .config 目录下。不同版本的具体文件名不一样，但都是文本格式。

我的建议是：第一次改完布局后，立刻把配置文件复制一份备份。理由是 LibreCAD 升级后偶尔会出现配置文件结构变化，导致自定义布局被重置。我们组就遇到过一次：某同事调了一上午的工具栏，软件一升级全部回到默认，最后靠备份文件恢复了。这属于典型的“不改代码但有后悔药”的场景。

4.2 改动翻译：让界面术语符合团队习惯

LibreCAD 内置了几十种语言的界面包，翻译源文件是 Qt 标准的 .ts 文件，发布后生成 .qm 文件供程序加载。如果你觉得某些术语翻译得不符合行业习惯，可以直接改。比如你们团队内部统一把“块”叫“图块”，把“多段线”叫“复合线”，这些都能通过修改翻译文件实现。

操作路径是先找到语言源文件，用 Qt Linguist 打开，在翻译单元格里替换译文，然后发布生成新的 .qm 文件。命令行里也可以直接合成：

# 把翻译源文件 .ts 编译成程序加载时使用的 .qm lrelease i18n/librecad_zh_CN.ts -qm librecad_zh_CN.qm # 覆盖到 LibreCAD 的翻译目录前，先备份原文件 cp librecad_zh_CN.qm /path/to/librecad/translations/

lrelease 是 Qt 自带的翻译发布工具，第一个参数是输入源文件，-qm 指定输出文件名，覆盖前备份是防止改完界面乱套。需要注意，这种改法影响的是界面文字，不影响图纸里的文字内容。图纸文字要改，得靠前面提到过的字体映射和文字替换思路，不是改翻译能解决的。

4.3 从源码编译一个定制版：CMake 参数与依赖

当界面定制、翻译定制都不够，你需要改实体读写逻辑或加命令时，就得走源码编译。LibreCAD 依赖 Qt 库、CMake 和 C++11 编译器，源码根目录下建 build 目录，配置时指定 Qt 的 CMake 路径，然后编译：

# 常见做法：在源码根目录外创建 build 目录，避免污染源码树 cmake -B build -DCMAKE_BUILD_TYPE=Release \ -DCMAKE_PREFIX_PATH=/path/to/Qt/lib/cmake # 并行编译，8 个任务只是示例，按机器核数调整 cmake --build build -j8

CMAKE_BUILD_TYPE 设为 Release 才能拿到可用的运行速度；CMAKE_PREFIX_PATH 指向 Qt 安装目录里的 cmake 子目录，是 CMake 找到 Qt 库的关键。编译产物在构建输出目录里，具体位置取决于生成器配置，但通常是 build/src 或 build/bin 下。编译过程的常见问题是 Qt 路径没配好导致找不到头文件，解决办法是把 CMAKE_PREFIX_PATH 换成实际路径并重新配置，而不是直接去改 CMakeLists。

5. LibreCAD 避坑指南：五个最容易翻车的地方与解决办法

5.1 高版本 DWG 缺实体或直接闪退

现象：打开一份较新版本的 DWG，图形少了一部分，块引用变成空壳，严重时程序直接退出。原因：DWG 格式是闭源的，实体类型日新月异，LibreCAD 的底层读取库对某些新实体只能跳过或降级处理。解决：要求来源方另存为 DXF 再发，或至少另存为旧版 DWG。如果拿不到 DXF，就用上游软件打开原图检查一遍缺失清单，而不是直接在 LibreCAD 里补画，容易画错。

5.2 导出 PDF 后中文变成方框

现象：屏幕上中文显示正常，导出 PDF 后文字变成一排方框，打印出来全是黑方块。原因：导出走打印管线，再次做字体匹配，系统找不到当前字体时就用了占位字体。尤其 SHX 形字体在 LibreCAD 里显示依赖字形绑定，导出后往往没有可用轮廓。解决：导出前在文本样式里把字体替换成系统已有的中文字体，例如思源黑体或 Noto Sans CJK，替换后再导。如果图纸已经被炸开成线，那就改不回来了，只能回到炸开前的备份。

5.3 文字被炸开成线段之后，没有后悔药

现象：有人为了让文字在不支持字体的软件里正常显示，把多行文字炸成线段，结果线段版本在 LibreCAD 里再也选不中文字内容，连查找替换都失效。原因：炸开后文字实体本身被拆散为普通图元，文本语义彻底丢失。解决：导出给别人的 SVG 或 PDF 之前，保留一份原始 DXF 当作母版，炸开只发生在导出副本上。千万别在唯一原件上炸文字，这是血泪经验。

5.4 圆弧方向反转导致下游加工走样

现象：一份 DXF 在 LibreCAD 里视觉完全正常，交给下游下料或雕刻程序后，圆弧切反了，轮廓过切。原因：不同软件对圆弧起点、终点和顺逆时针方向的约定不一致，LibreCAD 写出 DXF 时按自己的规则记录参数，而下游程序按另一套规则解释。视觉上你根本看不出方向问题。解决：导出给加工方前，先用对方软件或独立的 DXF 检查工具复核圆弧方向；涉及圆弧和样条线的图纸，不要只靠视图判断，把数据层面的一致性验证加进流程。

5.5 大图纸缩放卡顿，操作像泡在迟滞里

现象：打开几十 MB 的 DXF，每做一次缩放要等两三秒，图层一多更明显。原因：LibreCAD 的绘制是 CPU 软件渲染，实体量大时重绘开销高，没有 GPU 加速。解决：打开大文件后先关闭不需要的图层，关掉网格显示，把正交、捕捉提示等实时计算功能也关掉。还有一招是“清理”命令，删掉零长度实体和重复实体，体积降下来，操作流畅度会明显改善。如果你要长期处理大图纸，建议拆分文件而不是硬扛。

6. 让 LibreCAD 当图纸流水线终点：先用脚本洗 DXF，再出图、核对

每一次外部图纸进入 LibreCAD 之前，我都先跑一遍清洗脚本，这是最近一年最值回时间的习惯。清洗目标很简单：删掉零长度线段、替换缺失线型、记录文本样式，让 LibreCAD 打开的是一份“干净”的文件，而不是带着一堆历史包袱的原始档。

import ezdxf from pathlib import Path doc = ezdxf.readfile(Path("input.dxf")) msp = doc.modelspace() # 零长度 LINE 在 LibreCAD 里显示成一个点，缩放时拖慢渲染，先收集再删除 zero_lines = [] for e in msp: if e.dxftype() == "LINE": s, t = e.dxf.start, e.dxf.end if (t - s).magnitude < 1e-6: zero_lines.append(e) for e in zero_lines: msp.delete_entity(e) # 把文件里引用了但没定义的线型统一替换成 CONTINUOUS，避免显示成乱虚线 missing_linetypes = set() for e in msp: if not hasattr(e.dxf, "linetype"): continue lt = e.dxf.linetype if lt not in doc.linetypes: missing_linetypes.add(lt) e.dxf.linetype = "CONTINUOUS" doc.saveas("cleaned.dxf") print(f"清理零长度线段 {len(zero_lines)} 条，替换缺失线型 {len(missing_linetypes)} 种")

这段脚本先用 ezdxf 读取原始 DXF，第一轮遍历收集长度小于 1e-6 的直线，这个阈值对应 1e-6 个图纸单位，在毫米制下就是 0.001 毫米，足够安全。第二轮遍历检查每个实体的线型是否在文件的线型表里定义过，没有的定义就替换成 CONTINUOUS，避免 LibreCAD 打开时用不确定的规则乱画。最后保存为 cleaned.dxf 并打印清洗结果。

清洗完的文件交给 LibreCAD 打开，导出 PDF 后还要做一道核对工序：用 PDF 阅读器确认页数不为零，扫一眼有没有大块空白，再对照图层列表确认没有整层被隐藏。我自己吃过一次亏：一张标着“最终版”的图纸，清洗后导出 PDF 只有一页，打开才发现是某个图层被意外冻结，所有可见几何都集中在隐藏层里。

从那以后，我的流程固定成三步：脚本清洗、LibreCAD 出图、PDF 人工核验。核验这一步永远不省，因为 LibreCAD 的性能和兼容边界是真实的，它替你省下的时间，不应该在最后一道关上还回去。希望帮到你。

本文还有配套的精品资源，点击获取