SAHI 版本演进深度解析:从 v0.12.0 到 v0.12.8 的变更日志全景

发布时间:2026/10/12 3:21:34
SAHI 版本演进深度解析:从 v0.12.0 到 v0.12.8 的变更日志全景 计算机视觉人工智能【免费下载链接】sahiFramework agnostic sliced/tiled inference interactive ui error analysis plots项目地址https://gitcode.com/gh_mirrors/sa/sahi点击查看免费下载SAHI 是一个框架无关的切片/分块推理sliced/tiled inference工具库围绕图像切块预测、后处理合并NMS/NMM与 COCO 数据工具构建。本文以仓库根目录 CHANGELOG.md由 docs/tr/changelog.md 通过--8-- CHANGELOG.md引入为主线系统拆解 v0.12.0 以来的每一次版本发布每版新增了什么能力、修复了什么缺陷、性能数据如何变化并对照仓库源码如 sahi/models/libreyolo.py、sahi/utils/cv.py、sahi/postprocess/backends.py解释背后的实现原理。读完后你既能快速掌握 SAHI 各版本的能力边界与升级注意事项也能理解其后处理引擎从O(N²)稠密矩阵走向空间索引 按需读取的核心演进逻辑。版本总览SAHI 0.12.x 的演进主线从 v0.12.0 到 v0.12.8SAHI 的更新可以归纳为四条主线后处理引擎重构v0.12.0 引入可插拔的 NMS/NMM 后端NumPy / Numba / TorchVision与 shapely STRtree 空间索引v0.12.2 修复大规模预测集下的 OOMv0.12.5 将内存上界收紧为O(N max_degree)v0.12.6 将 NMM 合并簿记从二次复杂度降为线性。推理管线增强v0.12.0 实现端到端批处理切片推理、无 torch 核心v0.12.3 增加 Apple MPS 支持v0.12.7 让切片预测只解码一次源图像。模型生态扩展新增 GroundingDINO、YOLO-World、YOLOE、RF-DETR-Seg、YOLO26 等支持v0.12.8 引入 LibreYOLO 检测后端。COCO 工具链完善v0.12.7 为sahi coco evaluate增加 ultrafast-pycocotools 后端与 IoU 阈值列表支持多个版本持续修复类别重映射、掩码转换、OBB 转多边形等工具函数。SAHI v0.12.8LibreYOLO 后端与七个缺陷修复v0.12.8 是一个补丁版本核心动作有三新增LibreYOLO检测后端、修复七个涉及 COCO 类别重映射/切片/掩码转换/框合并的缺陷、并让布尔掩码构建速度提升约 8 倍。新特性LibreYOLO 检测后端LibreYOLO 是一个 MIT 许可、API 兼容 Ultralytics 的库。安装pip install libreyolo后即可通过model_typelibreyolo加载 LibreYOLO 模型。从源码看其实现 sahi/models/libreyolo.py 直接复用 Ultralytics 包装器from sahi.models.ultralytics import UltralyticsDetectionModel class LibreYoloDetectionModel(UltralyticsDetectionModel): def check_dependencies(self, packages: list[str] | None None) - None: super().check_dependencies(packages[libreyolo]) def load_model(self) - None: from libreyolo import LibreYOLO model LibreYOLO(self.model_path or LibreYOLO9t.pt, deviceself.device, taskself.task) self.set_model(model)check_dependencies只把依赖检查对象换成libreyoloload_model则用LibreYOLO构造器实例化模型其余检测、掩码转换、任务分发全部继承自 Ultralytics 包装器因此集成成本极低。该后端同时被 sahi/auto_model.py 纳入model_type分发模型指南见 docs/guides/models.md也以多语言形式覆盖了它。需要说明libreyolo仅作为pyproject.toml中 Python 3.10 的测试环境依赖出现见 pyproject.toml实际使用时需自行安装。修复一贴着切片边界的标注不再丢失当多边形的边恰好落在切片边界上时shapely 求交的结果会混杂多边形与线段导致标注以面积 0 被丢弃。v0.12.8 修正后保留多边形部分。这一修复直接影响sahi/slicing.py对 COCO 标注做切分时的结果完整性——小目标密集、多边形贴着切片边缘的场景这正是切片推理最常见的应用场景收益最明显。修复二NMM 合并重叠恰等于阈值的框此前当两个框的重叠度恰好等于match_threshold时它们会被认领却从未被真正合并结果既不出现在输出中keeper 框也不会扩大。修复后metric match_threshold的边界情况得到正确处理。这与后处理模块 sahi/postprocess/combine.py 中nmm的合并逻辑直接相关match_threshold默认为 0.5match_metric支持IOU与IOS。修复三get_bool_mask_from_coco_segmentation真正返回布尔数组此前该函数返回的是 float64 画布导致Mask.bool_mask无法用于图像索引。修复后的实现sahi/utils/cv.py把多边形填充在 uint8 画布上再转布尔def get_bool_mask_from_coco_segmentation(coco_segmentation, width, height): points [np.array(point).reshape(-1, 2).round().astype(int) for point in coco_segmentation] mask np.zeros((height, width), dtypenp.uint8) cv2.fillPoly(mask, points, (1,)) return mask.astype(bool)这个 uint8 画布的改动同时带来了性能红利官方在 Intel Core i7-13850HX 上测得构建 1080p 掩码耗时从1.03 ms 降到 0.13 ms约 8 倍内存占用降低 8 倍。原理很简单——float64 每个像素占 8 字节uint8 只占 1 字节填充与转换的开销也随之大幅下降。修复四七类别重映射、COCO 派生对象与空输入处理类别重映射只映射一次remapping_dict{0: 1, 1: 2}时两个类别都被映射成 id 2加载时抛KeyError。修复后每个 id 只映射一次。在 sahi/utils/coco.py 中remapping_dict用于Coco.from_coco_dict_or_path等入口如{1:0, 2:1}表示把类别 1 映射为 0相关测试见 tests/test_coco_utils.py。派生 Coco 对象保留类别对 COCO 对象做降采样、升采样、面积过滤、bbox 裁剪clip_bboxes_to_img_dimsTrue时此前会对已重映射的 id 再应用一次remapping_dict造成二次映射错误。修复后派生对象继承正确的类别映射。空检测集下的 NMM类别感知 NMMclass-aware NMM与贪婪 NMM 现在接受没有任何检测结果的图像不再抛AttributeError。空列表参数fix_shift_amount_list与fix_full_shape_list见 sahi/utils/compatibility.py现在接受空列表不再抛IndexError。这两个工具函数用于兼容 v0.8.15 及更早版本对shift_amount_list/full_shape_list的扁平格式会把[16, 16]这样的扁平列表规范化为[[16, 16]]空输入则返回[[0, 0]]/None。文档同步中文与土耳其语文档重新与英文文档对齐RT-DETR 指南改用后端实际加载的 Ultralytics 权重coco sliceCLI 文档不再列出其并不存在的--backend选项。SAHI v0.12.7ultrafast 评估后端、视频修复与性能提速v0.12.7 引入可选的ultrafast-pycocotoolsCOCO 评估后端修复四个崩溃/计数错误加速后处理与切片预测并把 Python 3.10 的 torch 版本下限提升到 2.13.0。新特性sahi coco evaluate支持 ultrafast 后端安装pip install sahi[ultrafast]pyproject.toml中对应依赖为ultrafast-pycocotools0.1.11,0.2见 pyproject.toml后CLI 传入--backend ultrafast或在 Python 侧调用sahi.scripts.coco_evaluation.evaluate时传backendultrafast即可切换。pycocotools 仍为默认后端。源码层面sahi/scripts/coco_evaluation.pyevaluate()的签名是def evaluate( dataset_json_path: str, result_json_path: str, out_dir: str | None None, type: Literal[bbox, segm] bbox, classwise: bool False, max_detections: int 500, iou_thrs: list[float] | float | None None, areas: list[int] [1024, 9216, 10000000000], return_dict: bool False, backend: Literal[pycocotools, ultrafast] pycocotools, ) - dict:非法 backend 会抛ValueErrorbackend ultrafast时从ultrafast_pycocotools导入COCO, COCOeval否则从pycocotools导入。测试 tests/test_coco_evaluation.py 通过参数化用例验证两个后端在max_detections ∈ {1, 500}、iou_thrs ∈ {None, 0.5, [0.5, 0.75]}下返回完全相同的 bbox 与 segm 结果且空结果文件也能正确处理。修复IoU 阈值列表、视频帧计数、COCO 工具函数IoU 阈值列表向evaluate传iou_thrs列表时此前会在汇总步骤因 NumPy nonzero on 0d arrays 报错。修复后阈值始终以数组形式存储。视频预测帧计数此前进度条总数只按frame_skip_interval计算且导出视频使用fps / frame_skip_interval而非fps / (frame_skip_interval 1)导致导出视频比源视频播放更快。修复后跳帧统计与导出帧率都正确。remove_invalid_coco_results见 sahi/utils/coco.py此前遇到 bbox 不足四个值的记录会抛IndexError现在直接跳过这类无效框。get_coco_segmentation_from_obb_points见 sahi/utils/cv.py用于把 ultralytics OBB 输出的(4, 2)点阵展平为 COCO 多边形[x1, y1, ..., x4, y4]并闭合首点空输入时现在返回空列表而非抛IndexError。性能后处理与切片预测NMS/贪婪 NMM 恢复存储配对路径自 v0.12.5 起它们总是按需从 STRtree 读取行在框分布稀疏时反而比存储好的配对列表慢。v0.12.7 让它们像 NMM 一样按框的拥挤程度选择路径输出保持不变。流式后处理丢弃已完成框已稳定的框从后续 STRtree 查询中移除拥挤输入下查询树随循环进行而不断缩小。切片预测只解码一次源图get_sliced_prediction此前会解码文件四次现在复用切片阶段已有的解码结果。slice_image峰值内存下降本地文件用 OpenCV 直接解码为 NumPy 数组不再经由 Pillowread_image_size从文件头读取尺寸而不解码图像16 位文件等 OpenCV 无法处理的情形仍走 Pillow 路径。构建与文档torch 版本下限Python 3.10 为 2.13.0Python 3.9 为 2.8.0Python 3.8 为 2.4.1各自仍有 wheel 的最新版本。开发安装会按机器匹配 CUDA 或 CPU 的 torch 构建CI 覆盖 Python 3.13/3.14。文档命令、默认值与示例与代码对齐coco evaluate现在列出--type segm、--max_detections、--backend新增一个在运行机器上测量批量切片推理速度、并校验批处理不改变检测结果的 notebook见 demo/inference_with_batch_slicing.ipynb。SAHI v0.12.6NMM 合并簿记从二次复杂度到线性v0.12.6 只有一个性能修复NMM 后处理在合并组变大时不再变慢——而这正是拥挤场景的典型形态。问题根因每个候选框先要在已并入当前 keeper 的框的 Python 列表里线性搜索之后才查merge_to_keep数组。拥挤场景下少数几个巨大的合并组让几乎所有候选框都付出了逐框搜索的成本。由于框追加进 merge 列表与写入merge_to_keep发生在同一步仅靠数组查询就已能回答是否已合并列表搜索纯属重复。删除它之后每个组的结果完全不变而合并簿记从组大小二次降为线性。收益面稠密dense、存储配对stored-pair与流式streaming三条路径共享这份簿记逻辑因此三者同时受益numba 后端经由稠密路径继承该改进。官方基准拥挤布局IOS / 0.3boxesbeforeafterspeedup2000324 ms199 ms1.6x50002132 ms896 ms2.4x1000013303 ms3531 ms3.8x2000080153 ms14625 ms5.5x33337297170 ms48926 ms6.1x注意框数从 2 万增长到 3.3 万时加速比从 5.5x 提升到 6.1x——组越大消除二次搜索的收益越明显。SAHI v0.12.5后处理内存工作收尾v0.12.2 开始的后处理内存改造在 v0.12.5 收尾。此前用每对相交框存一条记录替代N×N重叠矩阵只在框分布稀疏时省钱框互相堆叠切片推理在拥挤场景和小目标图像上的典型产物时相交对接近N²存储列表的代价与矩阵相当。修复一内存不再依赖拥挤程度。合并循环一次只读一行匹配NMS 与贪婪 NMM 只读存活框的行因此行改为按需从 STRtree 回答峰值内存上界为O(N max_degree)与布局无关NMM 每框读一行而非每存活框读一行因此在预测配对列表可能很大之前仍保留存储配对列表。修复二非正match_threshold不再构建度量矩阵。两种度量IOU/IOS恒非负match_threshold 0时metric 0对任意框对成立邻接图退化为完全图——这种完全不需要重叠计算的配置此前反而最昂贵并在 25000 框时复现了 issue #1374 的 OOM。源码中 sahi/postprocess/_numpy_backend.py 的matches_all_pairs()正是这一判断的体现阈值降到 0 时直接按分数顺序出结果跳过全部度量计算。修复三NMM 不再把 keeper 合并进自身。keeper 此前用merge_to_keep中留-1标记与未认领值相同导致后续处理可能认领 keeper 并把它追加进合并列表分数并列的重复框下会出现 keeper 出现在自己的合并列表里。修复后 keeper 指向自身不可被认领且不改变任何其他结果。修复四零面积框不再触发除零警告。度量对每对框计算inter / denom后再丢弃无效项退化框会发出RuntimeWarning现在改为掩码掉除零而不是掩码结果。性能基准IOS / 0.3layoutboxesNMS beforeNMS afterpeak memory beforepeak memory aftercrowded3333747180 ms135 ms3416 MB4 MBcrowded2000015931 ms57 ms1232 MB2 MBcrowded100002717 ms25 ms311 MB1 MBscattered33336539 ms188 ms65 MB4 MBnumba 后端按框密度选择路径其 NMS/贪婪 NMM 循环此前无论输入如何都做穷举两两扫描。若仅按预测数路由会回归拥挤场景JIT 循环会跳过已抑制候选在 numpy 方案失效后仍保持竞争力因此改为用框样本估计邻居数来决定路径。分数排序也从二次的插入排序改为各后端共享的lexsort顺序含并列完全一致。numba 后端基准20000 框average neighbours per boxNMS beforeNMS aftergreedy NMM beforegreedy NMM after0.0909 ms43 ms842 ms89 ms0.8781 ms52 ms757 ms84 ms5.1495 ms118 ms479 ms151 ms20.1241 ms146 ms236 ms148 ms78.9141 ms73 ms143 ms71 ms数据点证明邻居越少按需读取的收益越大邻居极多时 JIT 的抑制跳过机制依然有效。SAHI v0.12.4修复matplotlib缺失导致的 CLI 全面崩溃一个存量环境察觉不到、干净安装立刻翻车的经典缺陷sahi.cli导入sahi.scripts.coco_error_analysis后者在模块顶层导入matplotlib但matplotlib从未被列入[project].dependencies或任何 extra。由于导入是急切eager的干净安装下所有sahi命令都会失败——包括与绘图无关的sahi version。修复方式是把matplotlib声明为显式依赖。这也提醒使用者升级 SAHI 时若遇到 CLI 命令整体不可用优先检查依赖声明是否完整、pip install -e .是否被--no-deps干扰。SAHI v0.12.3Apple MPS 与土耳其语文档修复一Apple Silicon GPUMPS不再被忽略。select_device()此前只探测 CUDAmacOS 用户即使有可用的 Metal 后端也回退到 CPU。修复后自动选择顺序为CUDA → MPS → CPU检测通过torch.backends.mps.is_available()实现该 API 在所有受支持的 torch 版本上存在非 Apple 构建返回False检测到任一 GPU 时选择torchvision后处理后端。修复二线程 API 现代化。threading.currentThread()替换为current_thread()消除新版 Python 上的DeprecationWarning。文档与 CI新增土耳其语文档含构建步骤与 zensical.tr.toml 配置多语言子路径链接解析修复后端文档将 MPS 与 CUDA 并列设备选择与后处理后端解析由测试覆盖。性能参考IOU度量Apple M2 Pro5 次最优boxesnumpynumbatorchvision (MPS)1000.14 ms0.02 ms1.44 ms5001.53 ms0.36 ms1.42 ms10005.46 ms1.40 ms1.45 ms500081.37 ms34.16 ms4.05 ms200001237.70 ms462.56 ms11.75 ms大约 500 框以下 numba 仍然领先但差距约 1 ms 量级框数上去后 MPS 上的 TorchVision 后端优势显著。SAHI v0.12.2大规模后处理的 OOM 修复v0.12.2 直击大规模预测集后处理的内存崩溃与严重变慢共修复六类问题后处理不再为大输入分配N×N矩阵。背景v0.11 用 shapely STRtree 只比较邻近框v0.12 改为稠密矩阵时间和内存都是O(N²)且与布局无关。TorchVision 后端没有尺寸保护会在 GPU 上构建 7 个N×N张量最先 OOM。由于贪婪循环只使用matrix match_threshold从不使用度量值本身现在直接由 STRtree 报告相交的框对构建阈值化邻接矩阵并以 CSR 格式存储。CPU/CUDA 实测33337 框、IOS度量、阈值 0.3输出与修复前一致greedy_nmm6571 个预测、nmm4639 个CPUIntel Core i7-13850HXbackendgreedy_nmm beforeafternmm beforeafternumpy15.88s0.18s27.06s0.21storchvision6.22s0.18s17.34s0.21snumba1.53s1.55s18.56s0.22sCUDARTX 4000 Ada Laptop12 GBbackendgreedy_nmm beforeafternmm beforeafternumpy15.93s0.26s27.00s0.21storchvisionOOM, 4.14 GiB0.17sOOM, 4.14 GiB0.23snumba1.09s1.09s18.82s0.22s注意2000 框以下及任何非正阈值仍走稠密路径那里更快这正体现了 v0.12.5 中按拥挤度选路设计的延续性。其余修复RF-DETR 本地模型可按类名加载Roboflow 文档同步修正MMDetection 的has_mask处理RepeatDatasetsahi/utils/import_utils.py 强制依赖与最低版本检查所有 OpenCV 发行版统一到一个版本避免冲突安装。文档方面中文翻译更新完毕文档默认展示 YOLO26 并同步到 CLI 模型列表。SAHI v0.12.0重架构大版本v0.12.0 是发布以来最大的版本之一自 v0.11.34 起累计95 个提交并吸收了 0.11.35/0.11.36 热修复四大主题批处理推理、无 torch 核心与可插拔后处理后端端到端批处理切片以批次处理贯穿整条管线为 GPU 吞吐带来显著提升。无 torch 核心核心切片/后处理路径不再硬依赖 PyTorch用户只需安装后端所需依赖。可插拔后处理后端NMS/NMM 可在 NumPy零重依赖、NumbaJIT 加速 CPU、TorchVisionGPU之间选择并自动探测。后端分发逻辑见 sahi/postprocess/backends.pyresolve_backend()的优先级是torchvision已安装且 GPU 可用→ numba已安装→ numpy兜底可通过set_postprocess_backend强制指定合法值包括auto | numpy | numba | torchvision。新模型支持GroundingDINOHuggingFace文本提示的零样本开放词汇检测可走 SAHI 切片管线配套演示 notebook 见 demo/inference_for_huggingface.ipynb。HuggingFace 通用分割、RF-DETR-Seg 分割模型、YOLOE 检测模型、YOLO-World 开放词汇检测、YOLO26覆盖 Ultralytics 后端、CLI、文档与 notebook。切片与后处理的细粒度控制get_sliced_prediction新增force_postprocess_type参数各预测 API 支持每次调用覆盖confidence_thresholdPython API 与 CLI 都为get_sliced_prediction增加进度条与进度回调。性能与修复NMS/NMM/GREEDYNMM 改用 shapelySTRtree 空间索引多切片/多检测图像上的合并显著加速read_image_as_pil更快空预测处理更稳健BoundingBox边距计算修正get_slice_bboxes校验重叠率必须 1.0用自研轻量yolo_bbox_to_voc_bbox取代pybboxes。CI 全量固定 GitHub Actions 到 commit SHA供应链安全、多 OS 矩阵、Python 3.12/3.13、numpy3.0、torchvision 0.23.0。更早版本速览v0.11.x 关键节点版本关键内容v0.11.31Category不可变greedy_nmmdocstring 更新v0.11.30引用 SAHI 的学术论文达 400 篇修复get_sliced_prediction耗时统计正确区分 slice/prediction/postprocessUltralytics 支持重构ONNX 支持新增 Roboflow RF-DETR 支持移除无人维护的 deepsparse 集成测试套件迁移 pytestPython 3.8–3.12框与Category不可变线程安全分数运算符重载PyTorch 软依赖化v0.11.26新增 RoboflowRF-DETR框架OpenCV 4.11.0.86v0.11.24移除 deepsparsePyTorch 不再是硬依赖支持指定cuda:0之外设备select_device正则修复YOLOv8ONNX 增加 TensorRT 执行提供器v0.11.23修复 Polygon 修复与空多边形问题预测支持源目录中的 TIF 文件v0.11.22支持最新 mmdet v3.3.0、yolov5-pip/ultralytics、huggingface transformersCOCO→YOLO 转换重构v0.11.21推理时排除类别exclude_classes_prompt等OBB 演示 notebook移除 numpy2 上限v0.11.20YOLO11 与 ultralytics OBB 任务支持shapely 固定2.0.0v0.11.18YOLOv8 掩码支持掩码处理提速 4–5 倍v0.11.14Deci-AI YOLO-NAS 支持Detectron2 模型显著提速此外 v0.11.22 发布说明中还附带了核心文档索引predict/slicing/coco/cli/fiftyone指南与演示 notebook 清单其中多数文档可在 docs/predict.md、docs/slicing.md、docs/coco.md、docs/cli.md、docs/fiftyone.md 查阅。结语一条清晰的技术演进主线纵览 v0.12.x 的发布说明可以看到 SAHI 演进的三个核心判断后处理是性能主战场从N×N稠密矩阵 → STRtree 相交配对 → CSR 邻接 → 按需读取 按拥挤度选路每一步都在为切片推理在拥挤/小目标场景产生海量框这一实际工作负载服务性能数据OOM → 4 MB 峰值内存、80 秒 → 49 秒等是判断每一步成效的直接证据。依赖最小化是工程主线无 torch 核心、PyTorch 软依赖、可插拔后端、sahi[ultrafast]extra、libreyolo轻量集成——用户只安装自己后端所需的依赖。工具函数正确性反复打磨类别重映射、掩码布尔化、OBB 转多边形、空输入处理等细节缺陷被逐一修复并有测试守护见 tests/test_coco_utils.py、tests/test_coco_evaluation.py。升级建议若你在 macOS 上使用切片推理v0.12.3 起可获得 MPS 加速若处理超大图导致后处理 OOM升级到 v0.12.2并关注 v0.12.5/v0.12.6 的进一步优化若需要开放词汇检测v0.12.0 提供 GroundingDINO 与 YOLO-World 支持最新 v0.12.8 则带来了 LibreYOLO 后端与一批 COCO/掩码工具的健壮性修复。赞分享计算机视觉人工智能【免费下载链接】sahiFramework agnostic sliced/tiled inference interactive ui error analysis plots项目地址https://gitcode.com/gh_mirrors/sa/sahi点击查看免费下载相关推荐BootstrapVue 变更日志深度解读从 v2.0.0 到 v2.23.1 的版本演进全景BootstrapVue 变更日志深度解读从 v2.0.0 到 v2.23.1 的版本演进全景 本篇技术指南以 BootstrapVue 官方变更日志 do前端UI组件JAX 版本演进与变更日志深度解读从 0.1.58 到 0.11 的 API 演进全景JAX 版本演进与变更日志深度解读从 0.1.58 到 0.11 的 API 演进全景 JAX 是面向 Python NumPy 程序的可组合变换框架自人工智能机器学习深度学习编译器高性能计算yfinance 版本演进全解析从 0.0.1 到 1.6.0 的变更日志深度解读yfinance 版本演进全解析从 0.0.1 到 1.6.0 的变更日志深度解读 本篇文章基于仓库根目录 CHANGELOG.rst https://lin数据分析金融科技上一篇SM3-PHP终极指南在PHP中实现国密标准加密下一篇Img2Vec终极指南5分钟掌握PyTorch图像向量化技术创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询