简介：红豆地球V1.182正式版是一套面向地理信息查看、查询与分析场景的地图工具软件包，适合旅行规划、地理教学、商业分析及GIS入门用户使用。压缩包共208个文件，约62.94MB，采用7z格式打包；其中dll与exe构成程序运行主体，csv、bin、json、xml等承载地理数据与配置，png、doc、txt等辅助说明与界面资源，osgb、ive等则服务于三维场景展示。该版本为正式发行版，功能相对稳定，可提供地形、城市、道路等地理信息的浏览与缩放平移操作，并支持对地图数据进行一定程度的整合应用。基于GIS技术，软件可处理并呈现多来源地理信息，便于用户理解地图图层、数据组织与本地运行环境。目前已有2480人浏览学习，适合需要快速获取完整软件目录、研究地图工具文件结构，或用于本地部署实践与二次分析的用户参考。
1. 拿到「红豆地球V1.182」先别双击：桌面三维地图工具的定位与边界
地图工具这类东西，网页端和桌面端根本是两套使用体验。网页端开箱即用，但一断网就什么都做不了；桌面端要解压、要显卡、要自己配置数据源，可是跑起来之后，几百万平方公里的地形能随手拖着旋转，坐标拾取、点位标注、量算、导出全在本地完成。红豆地球V1.182 属于后者：一个 7z 绿色包，解压即用的三维地球浏览工具，核心能力围绕本地瓦片与高程数据的加载、球面坐标拾取和点位标注展开。
它适合两类人。一类是在内网或者没有外网的环境里需要看地形、核对点位的测绘、规划、外业复核从业者，打包带走就能用，不用等环境审批。另一类是想拿一份能改配置、能自己塞数据的桌面地图工具做验证的开发者，配置文件是明文的，瓦片目录是自己指定的，改起来没有黑匣子。不适合谁也得说清楚：它不解决 POI 检索，不是街景浏览器，别指望拿它当地图 App 用。
2. 解包到冷启动：7z 展开后的目录职责、显卡门槛与一次 GPU 验证
2.1 7z 解包：路径、编码和两个必改项
压缩包名字里带空格和中文，这是第一个坑的来源。Windows 自带解压对 7z 支持不全，别用右键「全部提取」，装个 7-Zip 或者用命令行。我一般直接解到盘符根目录下的英文短路径，理由后面会讲。
# 先列出包内结构，别急着全解，看清顶层目录是一层还是套了一层 7z l "红豆地球V1.182 - 正式版.7z" # 解包到英文短路径，-y 跳过覆盖确认，-o 后面不要有空格 7z x "红豆地球V1.182 - 正式版.7z" -o"D:\MapTools\hongdou" -y命令本身没什么难度，关键在参数背后的判断。7z l那一步是给自己省事：很多绿色包解开后里面还套一层同名目录，直接解到目标路径会变成hongdou\红豆地球\bin\...，后面配数据源路径时多一层，配置写错一半的锅都在这里。-o后面紧跟路径、不留空格，是 7z 的硬性语法，写成-o "D:\..."会把路径当成待解压文件。
提示：解包过程如果报 CRC 校验失败，别抱着侥幸心理继续跑。7z 的 CRC 是最靠谱的完整性信号，报错说明文件在传输或下载环节就坏了，这时候去排查显卡、驱动、运行库全是白费功夫。
第二个必改项是路径本身。中文路径、长路径、带空格的路径，在图形程序里翻车的概率远高于你的预期——不是每次都崩，而是某些资源加载线程用的是窄字符 API，读中文目录会静默失败，表现出来就是「地球出来了，瓦片一片白」。改路径的成本是三十秒，排查这个的成本是两小时。
2.2 目录结构逐层对照：哪些能动，哪些别碰
解压完先别点 exe，花两分钟把目录扫一遍。绿色包的结构基本都是下面这套逻辑，具体文件夹名各版本会有出入，但职责划分是一致的。
| 目录 / 文件 | 职责 | 能不能动 |
|---|---|---|
| 主程序 exe | 启动入口，命令行参数从这里传 | 别动，改名会导致相对路径失效 |
| runtime / bin | 打包的运行库、图形后端 DLL | 别动，缺一个就起不来 |
| data / res | 内置底图、图标、着色器 | 可替换，替换前先备份 |
| config / *.ini / *.json | 数据源路径、图层开关、缓存上限 | 主要改这里 |
| cache | 瓦片与地形缓存 | 可整目录清空，程序会重建 |
| plugins | 扩展模块，按需加载 | 视情况，出问题先清空 |
| logs | 运行日志 | 定期清，排查时第一时间看 |
判断一个绿色包做得好不好，看它有没有logs和config这两样就够了。有日志意味着出问题有第一现场，有明文配置意味着不用改注册表、不用碰安装器。这两点红豆地球这份包是齐的，所以后面所有的调参都能落地成「改一个键、重启、看日志」的闭环。
2.3 首次启动的三项环境核对
三维地球对环境的依赖比二维地图工具高一个量级，因为它要实时渲染球面网格、贴瓦片、叠地形。启动前后各核对一遍：
第一项，显卡与驱动。程序要的是硬件加速的 OpenGL 或 DirectX 后端，具体走哪条看日志里那行渲染后端声明。核显能跑，但缩放层级一高、地形一开就掉帧。我一般先在 Windows 的「图形设置」里把主程序显式指定到独显，别指望系统自动判断——双显卡笔记本上自动选择翻车是常态。
第二项，运行库。绿色包通常自带runtime，但如果程序一闪就退，先看是不是缺 VC++ 运行库。判断方法很简单：双击后任务管理器里进程出现又消失，事件查看器里有一条应用程序错误，模块名指向某个msvcp1xx.dll或vcruntime1xx.dll，那就是它。
第三项，磁盘与缓存目录权限。缓存目录如果落在C:\Program Files下面，普通用户没有写权限，程序会静默降级成不缓存，表现是每次拖动都重新解码，卡得莫名其妙。把整个包放在用户目录或非系统盘，这一条直接绕过去。
2.4 冷启动验证：确认它真的在用 GPU 渲染
这一步很多人跳过，然后带着一个软件渲染的地球抱怨「这工具真卡」。验证方法不需要装任何东西：
# 1) 记录启动前的 GPU 状态：任务管理器 -> 性能 -> GPU -> 3D 引擎占用 # 2) 启动程序并持续拖动地球 30 秒 # 3) 观察三个指标 # - GPU 3D 引擎占用是否明显抬升（软件渲染时接近 0） # - CPU 单核是否被吃满（软件渲染的典型特征） # - 日志里渲染后端那一行写的是什么判读标准：GPU 3D 占用抬升、CPU 单核不满，说明走的是硬件加速，正常。GPU 占用趴着不动、CPU 一个核跑满、风扇狂转，那就是掉到软件渲染了——原因通常是驱动版本太旧、显卡被系统禁用、或者远程桌面会话下没有硬件加速上下文。
注意：在远程桌面里跑三维程序，硬件加速经常拿不到，这不是程序的问题。要验证性能，必须在本地会话里测，远程里看到的帧率不能作为判断依据。
这一步做完，环境基线就有了。后面调数据源、调缓存、调地形，全都建立在「渲染链路是通的」这个前提上，不然你改十个参数也不知道是哪个生效了。
3. 挂数据源：瓦片金字塔、高程夸张与图层参数的六项取值
3.1 先搞懂瓦片编号：一张图算出 z/x/y
三维地球的底图本质是一堆正方形图片，按层级切好，程序根据当前视角算出该取哪几张。这套编号规则叫 Web 墨卡托瓦片金字塔：第 z 层把地球横竖各切 2^z 份，编号从左上角 (0,0) 开始。搞不清这个公式，就没法判断「为什么我放进去的瓦片一片空白」。
import math def lonlat_to_tile(lon, lat, z): """经纬度 -> 瓦片编号，用于核对本地瓦片目录里该有哪个文件""" n = 2 ** z x = int((lon + 180.0) / 360.0 * n) lat_rad = math.radians(lat) # 墨卡托投影的 y 是取对数的，别写成线性映射 y = int((1.0 - math.log(math.tan(lat_rad) + 1.0 / math.cos(lat_rad)) / math.pi) / 2.0 * n) # 边界钳制：极点和 180 度经线会算出越界值 x = min(max(x, 0), n - 1) y = min(max(y, 0), n - 1) return z, x, y def tile_bounds(z, x, y): """反算：这个瓦片覆盖的经纬度范围，用来验证拼缝和错层""" n = 2 ** z lon_l = x / n * 360.0 - 180.0 lon_r = (x + 1) / n * 360.0 - 180.0 lat_t = math.degrees(math.atan(math.sinh(math.pi * (1 - 2 * y / n)))) lat_b = math.degrees(math.atan(math.sinh(math.pi * (1 - 2 * (y + 1) / n)))) return lon_l, lat_b, lon_r, lat_t print(lonlat_to_tile(116.39, 39.91, 12)) # 输出 (12, 3411, 1577) 这样的三元组 print(tile_bounds(12, 3411, 1577)) # 反查覆盖范围两段函数的用途不一样。lonlat_to_tile是拿坐标去查文件——本地瓦片目录里到底有没有12/3411/1577.png，一查就知道是数据缺失还是配置写错。tile_bounds是反向验证，当你在屏幕上看到瓦片之间有错层、有偏移，用它算出相邻瓦片的边界该落在哪个经纬度，再和实际渲染位置对比，能立刻区分是「瓦片本身切错了」还是「程序把编号算错了」。
min(max(...))那两行钳制容易被省略，但极区和 180 度经线附近确实会生成越界编号，钳制掉比让程序去读一个不存在的文件要好。层级 z 的取值范围要看你的数据实际切到了几级，一般 3 到 16 级够用，超过 16 级的数据量是几何级增长，一张 7z 包塞不下。
3.2 本地瓦片目录的命名约定与配置项
程序不认识你的目录，它只认配置里那条路径模板。绝大多数这类工具用的是这几个占位符：{z}、{x}、{y}，个别版本还支持{-y}（TMS 方案，y 轴从下往上数）。这两套方案的 y 是反的，填错了表现是南北镜像——地球还是那个地球，地形全反了，第一次遇到会怀疑人生。
配置大概长这样，键名各版本可能不同，但结构一致：
{ "tile": { "scheme": "xyz", "url_template": "D:/MapTools/tiles/{z}/{x}/{y}.png", "zoom_min": 3, "zoom_max": 16, "format": "png" }, "terrain": { "dem_path": "D:/MapTools/dem", "exaggeration": 1.0 }, "cache": { "dir": "D:/MapTools/hongdou/cache", "size_mb": 2048 } }几个参数值得单独说。scheme填xyz还是tms，直接决定 y 轴方向，前面说的镜像问题就出在这里。url_template里用正斜杠，Windows 下反斜杠在 JSON 里是转义符，写成D:\MapTools\...会因为\M、\t被当成转义序列，路径直接损坏——这个坑不显眼，但踩一次能记一辈子。format要和实际文件后缀对上，程序按后缀拼文件名，后缀不对就是全空白。
zoom_min和zoom_max不是越大越好。设成 3 到 16，意味着用户拖到第 17 级时程序会停住，观感是「放大不了了」，但至少不卡死。设成 3 到 22，而数据只切到 14 级，用户一放大就是一堆请求打向不存在的文件，缓存目录里堆满错误占位图，越用越慢。
3.3 高程数据与地形夸张系数
影像瓦片给的是颜色，高程瓦片给的是形状。两者必须严格配准，同一个 z/x/y 编号必须在两个目录里都存在，缺一块的表现是山体上出现一片平掉的区域，边界整齐得像刀切的——那不是数据坑，是编号对不上。
地形夸张系数exaggeration是最容易被滥用的参数。默认 1.0 是真实比例，调到 2.0 到 3.0 山脉起伏会明显好看，视觉冲击强，很多演示图就是这么来的。但这个参数一旦偏离 1.0，所有基于高程的计算都不可信：剖面线会偏高、坡度会偏陡、视线分析全错。我的习惯是浏览时开 2.0，一旦要出量算结果，先改回 1.0 再算，改完再调回去。
注意：夸张系数是全局的，改一次影响所有图层。如果你在同一份配置里既做浏览又做量算，务必在日志里留一行记录当前值，不然过两天出的报告偏了多少自己都说不清。
高程数据的层级通常比影像低一到两级，这是正常的：影像要细节，地形只要轮廓。配置里dem_path指向的目录结构要和影像目录一致，否则程序找不到对应编号，整块区域会退化成平面。
3.4 图层参数速查表
调参时手边放一张表，比反复试错快。
| 参数 | 典型值 | 作用 | 调错的后果 |
|---|---|---|---|
scheme | xyz | y 轴方向 | 南北镜像 |
url_template | 含{z}/{x}/{y} | 瓦片定位 | 全空白 |
zoom_min/zoom_max | 3 / 16 | 可缩放层级 | 超出范围一片白 |
format | png | 拼后缀 | 拼出不存在的文件名 |
exaggeration | 1.0 | 地形夸张 | 量算结果失真 |
cache.size_mb | 2048 | 缓存上限 | 磁盘占满或频繁重解码 |
表里的「典型值」不是推荐值，是保底可用值。真要压榨性能，缓存上限按数据总量的一半给比较合适——太小了每次拖动都重新解码，太大了磁盘一直在涨。
4. 坐标闭环：从屏幕点拾取到 CSV 位号导入的四个环节
4.1 拾取的几何本质：射线与椭球求交
鼠标点在屏幕上，程序要回答的是「这个像素对应地球上哪个经纬度」。这不是二维地图那种简单的仿射变换，而是一道几何题：从相机位置发一条射线穿过鼠标位置，求它和 WGS84 椭球的交点。理解了这一点，拾取偏移的所有问题都能自己推。
import math import numpy as np WGS84_A = 6378137.0 WGS84_B = 6356752.314245 WGS84_E2 = 1 - (WGS84_B ** 2) / (WGS84_A ** 2) def ray_ellipsoid_lonlat(cam_ecef, dir_ecef): """相机位置 + 射线方向（地心直角坐标系）-> 交点经纬度""" o = np.array(cam_ecef, dtype=float) d = np.array(dir_ecef, dtype=float) d = d / np.linalg.norm(d) # 方向必须归一化，否则 t 没有物理意义 a, b = WGS84_A, WGS84_B # 椭球隐式方程 x²/a² + y²/a² + z²/b² = 1 代入射线参数方程，得到一元二次 A = (d[0] ** 2 + d[1] ** 2) / a ** 2 + d[2] ** 2 / b ** 2 B = 2 * ((o[0] * d[0] + o[1] * d[1]) / a ** 2 + o[2] * d[2] / b ** 2) C = (o[0] ** 2 + o[1] ** 2) / a ** 2 + o[2] ** 2 / b ** 2 - 1 disc = B * B - 4 * A * C if disc < 0: return None # 射线打到太空，没有交点 t = (-B - math.sqrt(disc)) / (2 * A) # 取近交点，远交点在背面 if t < 0: return None p = o + t * d lon = math.degrees(math.atan2(p[1], p[0])) # 地心纬度转大地纬度的单次近似，厘米级误差，要更准就迭代三次 lat = math.degrees(math.atan2(p[2], math.hypot(p[0], p[1]) * (1 - WGS84_E2))) return lon, lat这段代码的价值不在于直接抄进项目，而在于给你一把尺子。当程序拾取出来的坐标和预期差了几百米，你可以用同样的输入手算一遍，看是「射线算错了」还是「椭球参数用错了」。经验上，拾取偏移九成以上不是算法问题，而是底图本身带的坐标系偏移——下一节讲。
t取近交点那一行要注意符号。二次方程两个根，小的那个是射线射向地球表面的交点，大的是穿过地球打到背面的点。取反了，你在北半球点一下，拾取出来是南半球的对称点，这个错误第一次遇到时会非常困惑。
4.2 批量导入：CSV 字段规范与编码坑
单个点手动点还行，几十上百个点必须走批量导入。绝大多数这类工具接受 CSV，字段顺序和表头是关键。
import csv # 生成一份可直接导入的位号文件 rows = [ # name, lon, lat, alt（高程可选，留空则贴地） ("P-001", 116.3912, 39.9075, 52.0), ("P-002", 121.4737, 31.2304, 8.0), ("P-003", 113.2644, 23.1291, 21.5), ] with open("marks.csv", "w", newline="", encoding="utf-8-sig") as f: w = csv.writer(f) w.writerow(["name", "lon", "lat", "alt"]) w.writerows(rows)三个细节决定成败。第一，encoding="utf-8-sig"里的sig是给 Excel 看的，带 BOM 的文件 Excel 双击打开中文不乱码；但有些解析器会把 BOM 当成第一个字段名的一部分，导入后列名变成\ufeffname，匹配不上直接报错。遇到这种情况改成utf-8无 BOM。第二，newline=""不能省，Windows 下不加会在每行末尾多出一个空行，导入后一半记录是空的。第三，经纬度顺序，国内习惯「纬度在前」，国际惯例「经度在前」，导入前一定看一眼表头，反了的话点会全部跑到另一个半球，而且因为数值范围都在 -180 到 180 之间，程序不会报错，只会安静地全错。
提示：先用三个点试导入，确认位置对了再导全量。全量导错了要一条条删，试导入只要三十秒。
4.3 导出与投影：WGS84 与 GCJ-02 的偏移怎么处理
导出这一步最容易出问题的地方是坐标系。程序内部用 WGS84 椭球计算，但如果你叠的是国内常见的网络底图，那套瓦片本身带了几百米的非线性偏移（GCJ-02）。表现是：标注点看起来贴在某个路口，导出坐标拿去做外业复核，实际偏了一条街。
import math def dist_m(lon1, lat1, lon2, lat2): """两点平面距离的快速估算，用于量级判断，不做精密计算""" r = 6371000.0 x = math.radians(lon2 - lon1) * math.cos(math.radians((lat1 + lat2) / 2)) y = math.radians(lat2 - lat1) return math.hypot(x, y) * r # 同一地物：现场实测点 vs 程序里目视拾取点 d = dist_m(116.39120, 39.90750, 116.39578, 39.90812) print(f"偏差 {d:.1f} 米") # 落在 300~800 米区间就是典型的坐标系偏移判读规则很简单：偏差在 300 到 800 米之间，且方向随位置变化，那是坐标系转换没做，不是拾取算法错。偏差恒定在几米到几十米，方向固定，那是数据本身的配准误差，认了就行。偏差几百公里，那是经纬度顺序反了，回去查 CSV。
处理方式两条路：要么把底图换成无偏移的影像源，从根上解决；要么在导出后统一做一次坐标转换再交出去。我倾向第一条，因为第二条每转一次就多一次精度损失，而且没人记得住哪个文件转过、哪个没转过。真要做转换，转完必须拿一个已知控制点回验，偏差小于 10 米才算过关。
5. 避坑与排查：五条血泪记录的现象、成因与改法
5.1 启动后黑屏，转圈但不出球
现象：进程在，窗口出来了，中间一个加载动画转十几秒，然后要么白屏要么黑屏，日志里没有明显的错误行。
原因：九成是渲染上下文没建起来。常见触发条件是显卡驱动版本太旧、双显卡机器默认走了核显、或者程序跑在远程桌面会话里拿不到硬件加速。少数情况是runtime里的图形后端 DLL 被杀毒软件隔离了，文件在但被锁住，加载失败不报错。
解决：先在本地会话里重试，排除远程桌面；再看设备管理器有没有显卡告警；然后在 Windows 图形设置里把主程序显式绑定到独显；接着更新驱动；最后检查runtime目录下的 DLL 数量和安装包里的清单是否一致。这一套顺序是有讲究的，从成本最低的排查做起，别一上来就重装驱动。
5.2 瓦片拼缝明显，或者上下错了一层
现象：地球能转，影像也有，但相邻瓦片之间有细缝，或者整片区域的影像和地形明显错位一格。
原因：细缝是采样问题，瓦片边缘做了双线性过滤，边界像素被半透明化，通常把过滤方式改成单线性或者开启边缘钳制就好。错层则是 y 轴方向反了——tms和xyz的 y 是倒着数的，配置里填错一个字母，整块数据就上下翻。
解决：先用 3.1 里的tile_bounds算出某个编号该覆盖的经纬度范围，再到屏幕上比对实际渲染位置。对不上就改scheme，对上但边缘有缝就改过滤参数。这两个问题长得像但成因完全不同，别混在一起调。
5.3 标注点整体偏移几百米
现象：导入的位号在地球上看着「大概在那个位置」，但和影像上的明显地物对不上，偏了小半个街区。
原因：坐标系不匹配。标注数据是 WGS84，底图瓦片是带偏移的坐标系，两者叠加必然错位。这不是程序 bug，是数据源选型问题。
解决：优先换无偏移的底图。换不了就在导出环节统一做转换，转完拿控制点回验。绝对不要用「手动拖一拖对齐」的方式糊弄，一个点拖对了，换个区域又错，最后没人说得清数据到底对不对。
5.4 拖一会儿内存飙升，最后卡死
现象：刚启动时内存几百兆，转几分钟涨到几个 G，最后界面无响应。
原因：缓存没有淘汰策略，或者cache.size_mb设得过大又没做磁盘清理，同时内存里保留了所有解码后的纹理。三维地球的纹理是显存和内存双份占用的，层级一高就爆。
解决：把cache.size_mb调到数据总量的一半以内，确认淘汰策略是 LRU 而不是只进不出；定期清理cache目录；如果程序支持限制同时加载的瓦片数，把它压到 64 以内。这个参数调完要跑十分钟再下结论，短时间看不出来。
5.5 换台机器就加载失败
现象：在自己机器上一切正常，拷到同事机器上，程序能起，地球是白的。
原因：配置里写的是绝对路径，比如D:/MapTools/tiles/...，而对方机器上没有 D 盘或者路径不一样。另一种是路径里有中文，在对方的系统区域设置下解码失败。
解决：能用相对路径就用相对路径，相对主程序所在目录。必须用绝对路径时，把路径集中在一处配置里，拷机前改一行就够。中文路径的问题从解包那一步就该规避掉，别等到换了机器才发现。
6. 进阶改造：把绿色包变成可自检的离线底图工作区
绿色包最大的价值不是它能看地球，而是它的数据目录是开放的。既然瓦片是普通图片文件，那就可以用脚本管起来，把它当成一个自维护的离线底图工作区。
6.1 用脚本做瓦片完整性自检
数据来源杂，拷贝过程中断、下载不完整、磁盘坏道，都会留下一堆体积为零或者文件头损坏的图片。程序遇到这种文件不会报错，只会渲染成空白，而空白和「这里本来就没数据」在视觉上完全一样——这就是最坑的地方。
import sys from pathlib import Path MAGIC = (b'\x89PNG\r\n\x1a\n', b'\xff\xd8\xff', b'RIFF') def check_tiles(root, min_size=512): total, bad = 0, [] for p in Path(root).rglob('*'): if p.suffix.lower() not in ('.png', '.jpg', '.jpeg', '.webp'): continue total += 1 size = p.stat().st_size if size < min_size: # 占位图、中断写入的文件都在这个区间 bad.append((str(p), f'体积异常 {size}B')) continue with open(p, 'rb') as f: head = f.read(16) if not any(head.startswith(m) for m in MAGIC): bad.append((str(p), '文件头不匹配')) # 后缀是 png，内容不是 return total, bad total, bad = check_tiles(sys.argv[1]) print(f'扫描 {total} 张，异常 {len(bad)} 张') for path, reason in bad[:50]: print(f' {reason}\t{path}')min_size定在 512 字节是个经验值：正常瓦片再小也有几 KB，几百字节的基本都是错误占位图。MAGIC那一段是防「后缀骗人」——很多下载工具失败时会写一个 HTML 错误页然后强行改名成.png，体积不小，但文件头是<!DOCTYPE，程序解码失败照样白屏。扫出来的清单直接交给重新下载或者删除重建，比肉眼盯着地球找白块高效得多。
6.2 把自检和缓存清理串成固定流程
单次自检不算什么，把它固定成流程才有用。我的做法是三步：先扫瓦片完整性，出异常清单；再比对影像目录和高程目录的编号集合，找出只有影像没有地形的区格；最后清一遍cache，因为缓存里的旧解码结果会掩盖新数据的问题。
第二步的编号比对尤其值得做。影像和地形缺一块，视觉上只是山变平了，很容易被当成「这里本来就是平原」。用集合差集跑一遍，缺哪些 z/x/y 一目了然，比在三维场景里凭感觉找靠谱得多。
数据规模再大一点，可以给每个 z 层单独统计文件数和总体积，做成一张表。正常情况下每层的文件数应该是上一层的四倍左右，某一层数字明显偏低，说明那次切图中途断了，不用怀疑，直接重切那一层。
从那次把带偏移的底图和 WGS84 标注叠在一起、交出去一版全偏的数据之后，我每次开工前都强制走一遍「路径检查 → 瓦片自检 → 编号比对 → 控制点回验」这四步，二十分钟的事，省掉的是返工两天。希望帮到你。
本文还有配套的精品资源，点击获取
