先坦白一件事一个CAD软件的诞生最开始往往不是因为什么宏大的愿景而是被琐碎工作逼出来的。我在图纸管理部门干过一段时间每天面对成百上千张DWG被字体乱码、打印设置丢失、图纸合并错位、版本管理混乱这些事磨得心力交瘁。后来我开始琢磨与其指望别人发一个更好用的工具不如自己动手写一个。于是这个系列的第一篇就从零开始记录我做的CAD软件——第一阶段的项目调研、技术选型以及第一个能打开图纸的版本到底是怎么跑起来的。如果你也想过做图形类工具或者只是好奇DWG/DXF内部的那些弯弯绕绕这篇应该会给到你一些不一样的东西。1. 最初的想法为什么自己动手写CAD1.1 痛点是所有项目的起点我列过一张表把团队里的高频操作和低频操作分开。结果很扎心真正所有人天天用的加起来不到二十个命令——打开、缩放、平移、测量、标注、改字、图层开关、打印、批量合并。但要做到这二十个命令就得安装启动一个体积好几个GB的庞然大物。而且不同版本、不同电脑之间字体、打印设置、单位配置全部可能不一样。图在A电脑看是好的发到B电脑就垮掉。痛点其实不是功能少而是功能到不了普通用户手里。基于这个观察我的判断是垂直、轻量、可批处理比全面更重要。不是要和大型CAD工具拼功能而是把它最常用的场景拆出来做成一个不用培训也能上手的工具。用户要的不是百分之百的命令覆盖率而是打开一张图时它能按原样、按预期显示出来。1.2 目标用户与功能边界我把目标用户分成了三类一类是看图为主的像资料员、施工员、业主代表一类是需要简单编辑的比如造价、审图、装饰设计一类是要批量处理图纸的例如图档管理员、研发工程师。三类人需求差异其实很大但共同的核心诉求是把图纸正确、稳定地打开快速得到我要的信息不要被繁琐操作困住。于是我把当时的功能边界画得很死第一版只做打开、浏览、测量、批注、打印PDF、批量合并这一条主线。三维建模、参数化设计、动态块这些我全部砍掉。很多人问我为什么不做三维答案其实很朴素第一版的目标是验证“轻量看图”这条路能不能走通而不是一口吃成胖子。范围一缩再缩项目才没在第三周就夭折。1.3 为什么不做“大而全”CAD生态是几十年的积累任何一个个人开发者如果想把所有专业模块都覆盖到无异于重新发明一次轮子。大型CAD软件厉害的地方在于它的广度但这恰恰也是它让人望而生畏的地方。对于个人项目来说更现实的做法是从一个高频痛点切入把单个场景做到极致再考虑扩展。这个过程里最难的不是技术上实现某个功能而是持续拒绝那些听起来很诱人的新需求。我给自己立了一条规矩任何新功能先问它会不会强化“打开—查看—批注—输出”这条主线。如果不会就放到下一版。这条规矩帮我挡住了至少十个会让项目失控的想法。2. 动工前必须定的技术方案数据、内核与语言2.1 先从DXF说起图纸文件格式是绕不开的第一道坎。DWG是二进制格式由一家公司持续迭代公开资料和逆向成本都非常高DXF相比之下是公开的文本格式虽然结构啰嗦但好在你能一行一行看到它到底是什么。第一版我的计划是先彻底吃透DXF再通过第三方开源库去兼容DWG的常见子集。这一步请务必量力而行不要试图一夜之间自己写出一个DWG解析器那是别人积累几十年的护城河。正确的策略是“先解决自己能解决的问题剩下的用合力解决”。我在项目初期就把“DXF深度支持、DWG基础兼容”写进了技术路线图避免自己陷入无穷无尽的逆向工程。做文件解析时还要想清楚一个问题解析完的数据到底存在什么结构里。我踩过的坑是用链表组织所有图元结果合并图纸时图元一多查找性能就崩了。后来老老实实引入三层结构图层、块、图元先按图层过滤再按空间范围过滤性能立刻不一样。这段经验也算是后面做图纸合并的伏笔。2.2 为什么选C和Qt图形类工具对交互流畅度的要求摆在那里我最终选了C17加Qt 6。Qt有成熟的跨平台控件、稳定的信号槽机制Graphics View框架能撑住第一版的中等复杂度场景。如果只是想快速验证原型用Python加PySide6会更舒服但我从一开始就知道后面要做批处理和插件系统C和Python的混合架构更靠谱。这里有个小建议界面框架和绘制逻辑一定要解耦。千万别把图元坐标、视图变换、绘制这些代码全部塞进窗口类里否则后面想换OpenGL渲染时你会想哭。我第一版就把视图封装成一个独立的Viewport组件输入是图元列表输出是屏幕绘制指令。这样后续做性能优化才有操作空间。2.3 坐标系与精度为什么线条会挤到一个点很多用户遇到的“图纸线条都跑到了一个点”其实不止是看图软件的问题它更是坐标系统的经典事故。DWG可以记录很大的世界坐标比如道路工程图里坐标可能是几百万米级别。如果用单精度浮点保存这些坐标视觉上就会变成大量点重叠在一起。我做过一个估算单精度float的有效精度约是数值本身的1e-7倍。当数值到1e7量级时绝对误差已经到了米级连相邻线条都分不开。所以我的内核里所有坐标一律用double并且在渲染时先减去视口中心坐标再做缩放。这个“先平移再变换”的细节直接决定了大坐标图纸打开后是干净还是糊成一团。单位问题也很要命。有的图纸用毫米有的用英寸有的用米。合并图纸时如果不做单位换算尺寸看着是1实际可能错了几十倍。所以第一版我直接在文件读取时读取HEADER段里的单位标识然后统一换算成毫米内部数据始终保持同一个基准。这一步看似不起眼但它救了我无数个晚上。3. 第一个能打开图纸的版本实操过程与核心环节3.1 开发环境准备正式开始写代码之前我把环境基本固定下来了Windows 10 x64 Qt 6.5 LTS MSVC 2022编译器 C17。选择这个组合的原因很简单目标用户绝大多数都是WindowsQt LTS版本维护期长MSVC对DXF文件里的ANSI编码处理更成熟。环境里有一个小坑Qt的MinGW编译器和MSVC编译器会对某些接口产生微妙差异在跨编译器混用依赖库时会让你怀疑人生所以请全程只用一套工具链。然后是引入DXF解析库。开源社区有不少现成库可以帮你省时间但它们覆盖的版本有限字体、线型、块表这些边界情况需要自己补短板。我第一版的做法是把第三方库当作参考实现核心结构自己保存图元字段自己做映射。这样既不重复造轮子又保留了对细节的控制权。3.2 从文件到屏幕的四步管线我把它简化为四步读取、解析、归一化、绘制。读取阶段处理编码和文件路径解析阶段按段分类图元、图层、块表全部转入内部结构归一化阶段计算bounding box和单位换算绘制阶段才是真正的渲染。代码层面最有价值的一个优化是——坐标转换一定要放在绘制层而且要用双精度。我一开始写的版本是把double转成float再传给渲染结果在大图纸上明显能看到线条抖动。后来改成全部坐标以double在Viewport里做变换只在最后生成屏幕坐标时才转float。这个改动看似无关紧要却是我第一版渲染性能最值钱的一次优化。我贴一段简化后的思路你感受一下就好不需要当完整代码抄struct Viewport { double cx 0.0; // 视口中心 double cy 0.0; double scale 1.0; // 像素/毫米 QPointF toScreen(double x, double y) const { return QPointF((x - cx) * scale screenW / 2, (screenH / 2 - (y - cy) * scale)); } }; // 绘制时传入相对坐标避免大数直接做浮点计算 for (auto e : visibleEntities) { QPointF p0 viewport.toScreen(e.x0, e.y0); QPointF p1 viewport.toScreen(e.x1, e.y1); painter.drawLine(p0, p1); }关键是理解“相对坐标”这个思想而不是照抄代码。3.3 字体显示SHX字体和中文乱码的深坑图纸里的文字远不止“字体”两个字那么简单。DWG/DXF里最常见的是SHX字体这是一种CAD专用矢量字体普通操作系统根本没有。当你机器上没有对应的SHX文件时看图软件要么显示成一个个问号要么直接画成方框。第一版解决这个问题的思路是维护一张字体映射表把常见的SHX字体名优先映射到系统里已有的等宽或中文字体如果名字完全匹配不到则用日志记录并提供一个可选的“全局替换字体”让用户自己决定用什么字体来看图。另外还要照顾单行文字和多行文字的对齐方式。同一个文本在不同软件里可能因为宽度系数、对齐点、插入点不同而出现错位。我的经验是解析文字时要同时记录插入点和一个辅助对齐点渲染时优先用辅助对齐点做参考这样和CAD原生显示效果才最接近。我做测试时用了一批真实图纸其中一张的标题栏是竖排中文。结果字体替换后竖排变成横排彻底乱掉。后来才明白DWG里的文本还有旋转角度和镜像属性渲染时需要按角度应用变换。这些都属于“不做不知道一踩全知道”的细节。3.4 图纸合并坐标原点、图层命名与块名冲突图纸合并不是把两张图放在一起那么简单你首先要处理它们各自的坐标系。常见的情况是两张图原点不同、单位不同甚至图框方向都不同。我的处理方法是合并前同时打开两张图由用户在界面上指定一个基准点再以这个点为锚点把第二张图的全部坐标重新换算到第一张图的坐标系里。虽然麻烦但效果最可控。图层和块名冲突是我事先没预料到的。A图和B图都有一个叫“图层1”的图层但内容完全不是一回事如果直接合并图层列表会乱掉。解决方案是在合并时对非基准图的图层、块、文字样式统一加前缀例如把“图层1”改成“B-图层1”。这样视觉上名字虽然多了几个前缀但图层筛选再不会打架。这个合并功能后来意外地成为用户最常用的功能之一。大家都在吐槽图纸管理里最耗时的就是“收图、合并、出PDF、发出去”而我的工具正好踩中了这个流程。4. 安装与运行环境这个“无底洞”一个dll引发的血案4.1 用户机器上为什么会报vcruntime140_1.dll错误软件写好了更折腾的事还在后面——让它在别人电脑上能跑起来。分发出去的第一个测试版三天内收到最频繁的报错截图就是这个缺少vcruntime140_1.dll。这个文件不是软件的一个插件而是Microsoft Visual C运行库的一部分。很多经过精简的系统或者装过奇怪“优化工具”的电脑都缺少这一套运行库。但用户不这么想他只会觉得你这个软件是坏的。对普通用户的解决办法很简单去微软官网下载最新的Visual C Redistributablex64版本安装后重启电脑。但这个方案有个前提用户得愿意自己折腾。于是我更建议在软件的安装阶段就把它处理掉不要在用户打开软件那一刻才出事。这里我想多说一句正版软件和官方试用版真的足够用了完全没必要去网上找那些来路不明的安装包。运行库报错、安装失败、文件被病毒感染相当一部分都和来路不明的安装来源有关。4.2 安装进度条卡在90%的真实原因测试阶段还有一个高频现象安装进度条走到90%就停住过一会提示回滚。排查下来最常见的几个原因是安全软件拦截了写入临时目录的文件、旧版本残留导致覆盖失败、当前用户权限不足。而且90%这个位置往往是安装器在写注册表、复制DLL、创建快捷方式的密集阶段任何一个环节被卡住都会前功尽弃。我给自己的安装包增加了日志和重试逻辑每一步失败都会在日志里写清楚是文件复制还是注册表写入出了问题关键步骤做成可断点续装——用户修复完环境后重新运行不需要从头开始。为这个“90%魔咒”我加了差不多一周的工时但它直接减少了三分之二的安装类问题反馈。4.3 把运行库检查写进安装流程更彻底的办法是把运行库检查和安装直接嵌入到安装包。我用的安装工具是Inno Setup它可以写一个检查函数判断注册表里是否已安装了对应版本没有就静默安装vc_redist.x64.exe。类似这样的一段配置[Run] Filename: {tmp}\vc_redist.x64.exe; \ Parameters: /install /quiet /norestart; \ StatusMsg: 正在安装系统运行库请稍候...一个重要的细节必须先安装运行库再安装主程序顺序一定不能反。否则主程序安装完成后可能立即尝试运行这时候运行库还没有就位同样会报错。还有一个技巧静默安装运行库时加/norestart参数避免安装到一半系统自动重启把主程序安装打断。很多开发者觉得这种环境问题不属于“软件功能”不愿意花时间处理。但我的实际经验是用户对软件的第一印象根本不是你的功能多强而是打开那一刻是不是顺滑。把运行库、权限、路径这些“脏活”做好用户体验直接上一个台阶。5. 第一个对外测试版本功能、反馈与取舍5.1 首版功能清单对外测试版本的功能我列过一张表。现在回看仍觉得这个取舍是正确的功能模块首版状态备注打开DXF/DWG完成每天用真实图纸做回归测试缩放/平移完成大图纸性能仍需优化测量/标注完成精度统一用double批注完成独立图层保存打印PDF完成线宽、颜色映射有少量偏差批量合并图纸完成自动加前缀解决命名冲突批量打印规划中第二版再上Python脚本接口预留后续做二次开发能力三维显示明确不做与第一版目标无关表格背后的逻辑是主线优先所有能拼成“打开—查看—批注—输出”闭环的功能先做所有会分散精力的旁支一律往后面排。很多个人开发项目死于中期加需求我靠这张表反复提醒自己不要跑偏。5.2 用户反馈中最让我意外的事测试版发出去后反馈最多的事超出了我的预期。首当其冲的不是字体、不是打印而是批量打印。几十个用户都在问“能不能一次性把文件夹里所有图纸打印成PDF”。我意识到在设计院和工程公司的日常流程里最费时间的根本不是画图而是重复性极高的出图归档。这直接让我把第二版的批量打印提上了日程。另外一批人是来问图纸保护的他们想在发给甲方前给图纸加注水印、限制修改。这个需求背后其实是图纸版本管理和流程合规问题。对于真正的图纸保护更合适的做法是在企业层面推动正版授权和规范的图纸分发流程而不是寄希望于某个插件去“锁死”文件。我们拒绝提供这类绕开许可限制的功能也在测试版回复里写得很明确。设计师们对Python脚本的需求也让我很意外。他们希望自己写几句脚本把几十张图里的图号批量改掉而不是一张张手动操作。这说明垂直工具的竞争力不在功能数量而在于能不能融入用户已有的工作流。5.3 给未来自己留的接口二次开发与批处理因为有了上面的反馈我在第一版代码里开始预留两层接口。第一层是命令行提供类似cadtool merge -o output.dwg input1.dwg input2.dwg的批量入口第二层是Python脚本API把打开、测量、修改文字、导出PDF这些核心能力暴露给用户。两层接口都走同一个内核避免出现两套行为不一致的逻辑。也要认真考虑插件系统的隔离性。如果一个插件崩溃导致整个软件退出用户会恨死你的。我的方案是把插件做成独立进程或沙箱主程序只通过协议通信。第一版还没完全做完但这个设计方向在我心里很明确。6. 常见问题与排查技巧实录6.1 高频故障速查表把第一阶段的用户反馈整理成一个速查表基本就是这段时间踩坑的总集用户现象根本原因处理建议缺少vcruntime140_1.dll系统缺少VC运行库装官方Visual C Redistributable x64并重启安装卡在90%安全软件拦截/旧版本残留/权限不足管理员重试临时关闭防护清理安装残留打开图纸全是问号或方框SHX字体缺失配置字体映射表替换为中文字体图纸线条都挤到一个点坐标范围过大或单位混乱检查单位设置执行“范围缩放”内核统一用double从GIS导出的CAD坐标偏移投影坐标系/原点不一致先统一坐标系基准再做平移旋转CREO/SW导入CAD位置错乱各软件单位、插入基点不同在源软件中配置统一模板与映射文件admint.dll相关报错运行库或环境异常检查VC运行库更新系统重装软件这个表里的每一条都有对应的真实案例。印象最深的是一个GIS转CAD偏移问题用户发来的坐标和图形完全对不上后来发现他在GIS里用的是经纬度投影导出到CAD时忘了做投影切换。图纸管理和格式转换这类问题很多时候不是看图的软件不行是上游坐标系在源头就错了。6.2 送给开发者的四条忠告如果这个系列只能留下四句话我会写下这些第一日志是救命稻草。远程用户报错你没法看到他的屏幕只能靠日志判断。我第一版就写了完整的分级日志文件读取、坐标换算、字体映射、安装过程都有记录。正因为这些日志才能在用户描述不清问题时第一轮就定位到方向。第二一定要有样张图库。光是满足“能打开一张图”太容易了真正考验人的是各种极端情况。我建了一个测试文件夹里面包含了不同AutoCAD版本、不同单位、不同字体、带外部参照、巨大坐标、含密码保护的各种图纸。任何改动都要跑一遍样张集合否则根本不知道哪一步会破坏已有功能。第三兼容性测试要用白纸黑字的清单。我用一个电子表格记录了每台测试电脑的Windows版本、架构、是否安装VC运行库、软件测试结果。后来凡是出现“你那边怎么正常、到我这边就出问题”的情况先翻这张表大部分都能找到答案。第四清空环境测试永远不要省。每隔一段时间我会在一台刚装好操作系统、没有多余软件的干净机器上完整装一遍自己的软件模拟新用户的体验。这个动作往往能暴露出我在开发机上完全复现不了的安装和运行问题。7. 这一段来时路的个人体会写到这里第一阶段的记录差不多该收尾了。我第一次亲眼看到自己写的软件把一张DXF图纸完整画出来的时候屏幕里其实只有一个圆和两行文字渲染用了接近800毫秒但我站在电脑前看了很久。那个瞬间让人觉得解决具体问题的能力大概就是做软件这件事最迷人的地方。真正让这个项目活下来的其实不是那天的兴奋感而是一堆很不起眼的工作字体映射表补齐了没有、安装包有没有在别人的电脑上踩雷、几张从GIS导出的图纸坐标到底差在哪里。这些问题每一个单独拿出来都不算大但叠加起来就是用户会不会坚持用你的软件的全部理由。这个系列如果继续写我会顺着往后讲批量打印、插件接口、性能调优这些后续阶段。如果你也有自己动手做工具的想法我的实际建议是不要一开始就想着做多大多全先把“打开一个文件让它正确显示”这件事做到极致。其余的一切都会从这一步慢慢长出来。
