PLY文件头解析必须手动逐行读取，因头部结构松散、顺序不固定，fscanf易错位；需用getline逐行匹配element/property/end_header，严格按format字段区分ASCII/binary模式，并依type映射表读取对应字节数。
PLY 文件头解析必须手动逐行读取，不能依赖 fscanf 直接跳过
PLY 格式头部是纯文本，但结构松散：有注释（comment）、元素声明（element vertex 1000）、属性定义（property float x），顺序不固定，且可能混杂空行或额外空格。用 fscanf 尝试按固定格式读取（如 fscanf(fp, "element %s %d", name, &count)）极易因空格/换行错位而失败，甚至导致后续二进制数据读偏。
正确做法是用 std::getline 逐行读入，再对每行做字符串前缀匹配：
std::string line;
while (std::getline(in, line)) {
if (line.substr(0, 7) == "element") {
std::istringstream iss(line.substr(8));
std::string elem_name; int count;
iss >> elem_name >> count;
// 存入 elements[elem_name] = count
} else if (line.substr(0, 8) == "property") {
// 解析 type 和 name，注意区分 list uchar int vertex_indices 这类变长属性
} else if (line == "end_header") break;
}特别注意：property list 类型需额外提取长度类型（如 uchar）和元素类型（如 int），不能只看第三个词。
ply_property 的 type 字段决定实际内存布局，不是所有 float 都占 4 字节
PLY 规范中 type 是逻辑类型（如 float、uint8），但文件存储时可能映射为不同底层类型。例如 property float z 在 ASCII 模式下是文本浮点数，在二进制模式下通常是 float32；但若文件声明为 property double x，二进制段就按 8 字节双精度读——不校验 header 中的 type 与实际读取字节数是否一致，会导致整个点云坐标错位。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 维护一个 type 映射表，将 PLY type 字符串转为 C++ 类型大小和读取函数，例如：
"float"→sizeof(float)+fread(&f, 1, 4, fp) - 对二进制格式，必须严格按 header 中每个
property的 type 顺序和 size 累计偏移，不能假设所有属性都是 float - 遇到
property list uchar int face，先读 1 字节 uchar 得到长度 N，再连续读 N 个 int ——中间不能有任何对齐填充
ASCII 与 binary_little_endian 混用会静默损坏数据，必须在解析前确认 format 行
PLY 头部第一行是 format ascii 1.0 或 format binary_little_endian 1.0（或 binary_big_endian）。如果代码默认按二进制读，但文件其实是 ASCII，fread 会把文本字符当 raw bytes 解释，产生完全不可读的数值；反之，用 std::cin >> 读二进制文件则会在遇到 0x00 时提前截断。
关键检查点：
- 读完 header 后，必须检查
format字段值，并分支处理：ASCII 走std::istringstream逐字段解析，binary 走fread+ 类型映射 - big_endian 文件在 x86 主机上必须手动字节翻转，
ntohl/ntohs不适用（它们只针对网络序），应使用std::byteswap（C++23）或自定义宏 - 某些扫描仪导出的 PLY 声称是 binary_little_endian，但实际写成了 ASCII —— 最好加一行校验：尝试读前 4 字节，若出现可打印 ASCII 字符（如 'v','e','r','t'），立即报错并切换模式
element 间无分隔符，属性顺序即内存顺序，跨 element 读取易越界
PLY 允许定义多个 element（如 vertex 和 face），但二进制段中它们是连续排列的：先存完全部 vertex 数据，再紧接全部 face 数据。如果只解析了 vertex 的属性，却按总 element 数去循环读，就会把 face 数据误当 vertex 坐标读入。
安全做法：
- 为每个
element单独维护其属性列表、总数量、单条记录字节数（sum of each property's size） - 读 vertex 时，只循环
elements["vertex"].count次，每次读elements["vertex"].stride字节 - 读 face 前，先 fseek 到 vertex 数据末尾（
vertex_count * vertex_stride），再开始读 face 数据 - 不要假设 vertex 一定在 face 前面 —— 虽然常见，但规范允许任意顺序，必须依赖 header 中
element出现顺序
最易被忽略的是 stride 计算：若有 property list uchar int indices，它不贡献固定字节，而是在每条 record 中动态变化，此时该 element 无法用简单 fseek 跳转，必须流式顺序读取。
