<think>
根据提供的代码，问题在于从数据库中读取的dhcp_option_bind和配置的option无法正确显示。
在函数`dhcpServerManualBindOutput`中，我们注意到它调用了`uiDhcpServerGetManualBindWithOptionByCid`来获取手动绑定的选项（option）。
然后，它遍历`getoptionList`数组，将非零选项码的选项值存入JSON对象。但是，在返回的JSON中，`dhcp_option_bind`字段是根据`optCount`是否为0来设置为"on"或"off"的。
然而，从提供的Redis数据来看，确实有option60和option150，但为什么在页面上没有显示？
让我们分析可能的原因：
1. `uiDhcpServerGetManualBindWithOptionByCid`函数可能没有正确获取到选项。
2. 在`dhcpServerManualBindOutput`中，`ret = uiDhcpServerGetManualBindWithOptionByCid(...)`的返回值可能不是`ERR_NO_ERROR`，导致没有正确填充`getoptionList`。
3. 在`uiDhcpServerGetManualBindWithOptionByCid`函数中，我们注意到它通过迭代器遍历配置项，然后比较cidStr（在这里是MAC地址）来找到匹配项。但是，在Redis中存储的MAC地址是"00-0A-EB-00-13-04"，而传入的`manualBind.macStr`的格式可能不同？比如可能没有横线或者大小写问题？
在`dhcpServerManualBindOutput`中，我们传入的`manualBind.macStr`是结构体中的值，而结构体`manualBind`是从哪里来的？它可能是从上层调用传入的，而这个MAC地址的格式可能与Redis中存储的格式不一致。
另外，在`uiDhcpServerGetManualBindWithOptionByCid`函数中，它使用`tpConfig_get`来获取配置，然后迭代查找匹配项。这里有一个问题：在迭代过程中，它只比较了`cidField`（即MAC地址或客户端ID）是否相等，但注意Redis中存储的MAC地址是带横线的，而传入的MAC地址格式是否一致？
在`dhcpServerManualBindOutput`中，我们打印一下传入的`manualBind.macStr`和从Redis中读取的MAC地址，看看是否一致。
但是，由于代码中并没有日志输出，我们可以通过添加日志来调试。
然而，问题中已经说明读取不到正确的option，所以我们需要检查：
1. 在`dhcpServerManualBindOutput`中，调用`uiDhcpServerGetManualBindWithOptionByCid`之后，`ret`的值是什么？如果非0，则说明获取失败。
2. 在`uiDhcpServerGetManualBindWithOptionByCid`中，我们使用`snprintf(entryKey, sizeof(entryKey), UC_DS_MANUAL_BIND_ENTRY_POOL_ALL, poolName);`，其中`UC_DS_MANUAL_BIND_ENTRY_POOL_ALL`的定义是什么？从代码中看，它可能是`UC_DS_MANUAL_BIND_ENTRY:%s|*`，这样会匹配该pool下的所有绑定。但是，在Redis中，键是`UC_DS_MANUAL_BIND_ENTRY:LAN1|3232235631`，所以这个模糊匹配应该能匹配到。
但是，在迭代过程中，我们比较的是`cidField`（即`UC_DS_MANUAL_BIND_TBL_MAC`）的值是否等于传入的`cidStr`（即MAC地址）。在Redis中，该字段的值是"00-0A-EB-00-13-04"。那么传入的`manualBind.macStr`是什么？在`dhcpServerManualBindOutput`中，这个`manualBind`是从参数`data`中得来的，而`data`是上层迭代传入的。我们需要确保在这个结构体中，MAC地址的格式也是"00-0A-EB-00-13-04"。
另外，在`uiDhcpServerGetManualBindWithOptionByCid`中，我们使用`STR_EQUAL`来比较字符串，这个宏可能是大小写敏感的，而Redis中的MAC地址是大写的，传入的可能是小写？或者相反？
另一种可能：在`dhcpServerManualBindOutput`中，我们调用了`uiDhcpServerGetManualBindWithOptionByCid`，传入的第四个参数是`&manual_bind`，然后这个结构体在函数中并没有被使用（除了初始化），而在获取选项后，我们也没有将选项信息关联到输出的JSON中，而是直接将选项值设置到JSON对象中。这看起来没有问题。
但是，为什么在页面上没有显示option60和option150？可能是因为在`uiDhcpServerGetManualBindWithOptionByCid`中，并没有成功获取到选项。
我们再看`uiDhcpServerGetManualBindWithOptionByCid`函数，它调用`uiDhcpServerGetManualBindWithOption`来获取选项。这个函数（未提供）可能从配置库中读取选项。但是，在Redis中，我们已经看到了option60和option150，所以这个函数应该能读到。
但是，在迭代过程中，我们只取第一个匹配的字段？注意，在迭代FV（字段值）时，我们只取第一个`cidField`字段，然后比较，然后跳出循环。这应该没问题，因为每个键对应的`cidField`字段只有一个值。
然而，还有一个问题：在Redis中，我们看到的键是`UC_DS_MANUAL_BIND_ENTRY:LAN1|3232235631`，而我们在`uiDhcpServerGetManualBindWithOptionByCid`中构造的模糊匹配键是`UC_DS_MANUAL_BIND_ENTRY:LAN1|*`，这应该能匹配到。然后我们解析键名：`dhcpPoolAboutKeyNameParse(pKey, UC_DS_MANUAL_BIND_ENTRY_FMT, tmpPoolName, &ip.s_addr)`，这里`UC_DS_MANUAL_BIND_ENTRY_FMT`可能是`UC_DS_MANUAL_BIND_ENTRY:%[^|]|%s`，这样就能解析出poolName和IP地址。但是，在Redis键中，IP地址是以整数形式存储的（3232235631），而`dhcpPoolAboutKeyNameParse`中可能需要的是点分十进制？或者直接是字符串？从代码中看，它用`&ip.s_addr`来接收，而`s_addr`是`in_addr_t`（32位整数），所以这里应该直接存储整数。但是，在Redis键中，我们看到的IP部分是整数（3232235631），这个整数就是IP地址的整数形式（192.168.1.47的整数形式是3232235823？）。但是，我们注意到在Redis中，`UC_DS_MANUAL_BIND_TBL_IP`字段的值也是"3232235631"。所以解析键的时候，应该将这个字符串转换成整数，然后赋值给ip.s_addr。但是，在`dhcpPoolAboutKeyNameParse`函数中，我们是如何解析的？
由于没有提供`dhcpPoolAboutKeyNameParse`的代码，我们假设它能正确解析。
但是，在`uiDhcpServerGetManualBindWithOption`函数（未提供）中，它可能使用这个IP地址和poolName去获取选项。但是，在Redis中，我们存储的选项是直接在该哈希表中的，比如`optionType60`，`optionVal60`等。所以，在`uiDhcpServerGetManualBindWithOption`中，应该会从同一个键中读取这些字段。
那么，为什么没有读取到呢？
可能的原因：
1. 在`uiDhcpServerGetManualBindWithOption`中，读取选项的代码有误。
2. 在`uiDhcpServerGetManualBindWithOptionByCid`中，我们在找到匹配项后，调用`uiDhcpServerGetManualBindWithOption`，但是传入的`ip`和`poolName`是否与Redis中的键匹配？在Redis中，键是`UC_DS_MANUAL_BIND_ENTRY:LAN1|3232235631`，而传入的`ip`是从键中解析出来的，所以应该是3232235631，而poolName是`LAN1`。所以，在`uiDhcpServerGetManualBindWithOption`中，应该会构造同样的键去读取。但是，在`uiDhcpServerGetManualBindWithOption`中，是否能够正确读取到选项字段？
由于没有提供`uiDhcpServerGetManualBindWithOption`的代码，我们无法进一步判断。
但是，在`dhcpServerManualBindOutput`函数中，我们还有另一种方式来获取选项：它调用了`uiDhcpServerGetManualBindWithOptionByCid`，然后遍历`getoptionList`。如果这个列表没有填充，那么`optCount`为0，导致`dhcp_option_bind`被设置为"off"。
所以，问题很可能出在`uiDhcpServerGetManualBindWithOptionByCid`或`uiDhcpServerGetManualBindWithOption`函数中。
建议的调试步骤：
1. 检查`uiDhcpServerGetManualBindWithOptionByCid`的返回值。如果返回错误，那么就不会填充选项。
2. 在`uiDhcpServerGetManualBindWithOptionByCid`中，确保找到了匹配的项（即`findFlag`为真）。
3. 在`uiDhcpServerGetManualBindWithOptionByCid`中，调用`uiDhcpServerGetManualBindWithOption`后，检查其返回值。
4. 在`uiDhcpServerGetManualBindWithOption`中，检查它是否能够正确读取选项字段。
另外，注意在Redis中，选项的字段名是`optionType60`和`optionVal60`，而在代码中，我们使用`OPTION`结构体的`code`和`valStr`来存储。在`uiDhcpServerGetManualBindWithOption`中，应该将这些字段的值读入`OPTION`结构体。
由于我们没有`uiDhcpServerGetManualBindWithOption`的代码，这里只能推测。
但是，在`dhcpServerManualBindOutput`中，我们分配了`getoptionList`为255个选项，然后传递给`uiDhcpServerGetManualBindWithOptionByCid`。在`uiDhcpServerGetManualBindWithOptionByCid`中，又传递给`uiDhcpServerGetManualBindWithOption`。在`uiDhcpServerGetManualBindWithOption`中，应该会填充这个数组。
然而，在Redis中，每个绑定可能有多个选项，但代码中只处理了60和150，所以应该能读到两个选项。那么`optCount`应该是2，从而`dhcp_option_bind`为"on"。
但是，如果`uiDhcpServerGetManualBindWithOption`没有正确填充，那么`optCount`为0。
因此，问题很可能在`uiDhcpServerGetManualBindWithOption`函数中。
由于没有提供该函数，我们无法进一步分析。但是，我们可以检查另一个地方：在`dhcpServerManualBindOutput`中，我们注意到在调用`uiDhcpServerGetManualBindWithOptionByCid`之前，已经有一个`manualBind`结构体，它包含了从上层传递来的信息。然后我们调用`uiDhcpServerGetManualBindWithOptionByCid`时，传入的`cidStr`是`manualBind.macStr`，而`isMac`为TRUE，`poolName`为`manualBind.poolName`。然后，我们使用这些去查找，但是，在Redis中，键是由IP地址和poolName构成的，而这里我们使用MAC地址去匹配。所以，在Redis中，每个绑定项都有一个MAC地址字段，所以这样匹配是可行的。
但是，在Redis中，我们看到的MAC地址是"00-0A-EB-00-13-04"，而`manualBind.macStr`的格式是否一致？我们可以通过日志输出比较。
建议在`dhcpServerManualBindOutput`中添加日志，输出`manualBind.macStr`和`manualBind.poolName`，然后在`uiDhcpServerGetManualBindWithOptionByCid`中添加日志，输出从Redis中读取的MAC地址和传入的MAC地址，以及比较结果。
另外，在`uiDhcpServerGetManualBindWithOptionByCid`中，在调用`uiDhcpServerGetManualBindWithOption`后，可以检查填充的`optionList`数组，看是否有数据。
由于代码中没有提供调试信息，我们只能根据已有代码推测。
但是，我们注意到在`dhcpServerManualBindOutput`中，有一个条件判断：
if (0 != strlen(manualBind.vrfName))
{
return ERR_NO_ERROR;
}
如果`manualBind.vrfName`不为空，则直接返回。但是，在Redis中没有看到vrfName字段，所以这里可能是空的，不会影响。
综上所述，可能的原因有：
1. MAC地址格式不一致（如大小写、分隔符等）。
2. `uiDhcpServerGetManualBindWithOption`函数未能正确读取选项。
解决方案：
1. 确保MAC地址的格式一致。可以在比较之前进行标准化（比如统一转成大写，或者统一转成小写，以及统一分隔符）。
2. 检查`uiDhcpServerGetManualBindWithOption`函数的实现，确保它从正确的键中读取选项字段。
由于无法修改未提供的函数，我们可以尝试在`uiDhcpServerGetManualBindWithOptionByCid`中，将传入的MAC地址转换成Redis中存储的格式（即带横线的大写格式）。
例如，在调用`STR_EQUAL`之前，将传入的`cidStr`和从Redis读取的`pStr`都转换成统一的格式。
修改`uiDhcpServerGetManualBindWithOptionByCid`函数中比较的部分：
我们可以添加一个函数来标准化MAC地址的格式，比如将字母都转为大写，并且确保分隔符是横线。
但是，在代码中，我们不知道传入的`cidStr`的格式。所以，我们可以这样：
在`uiDhcpServerGetManualBindWithOptionByCid`中，当`isMac`为TRUE时，我们将传入的`cidStr`和从Redis读取的`pStr`都标准化为同一格式（比如去掉分隔符并转为大写，或者转为带横线的大写）再比较。
由于没有提供标准化函数，我们可以写一个：
```c
void standardizeMacAddress(char *mac) {
// 这里实现标准化函数，例如将mac地址转为大写，并将分隔符统一为横线或去掉
// 由于实现可能较复杂，且不是重点，这里略过
}
```
但是，我们也可以尝试在比较前临时转换。
不过，为了快速验证，我们可以在日志中输出两个字符串，然后观察格式差异。
如果确实存在格式问题，那么就需要在比较前进行标准化。
由于时间限制，这里提供一个简单的修改：将两个字符串都转为大写，并替换冒号或点号为横线（如果存在的话），但注意Redis中已经是横线。
修改代码：
在`uiDhcpServerGetManualBindWithOptionByCid`函数中，在比较字符串之前，先标准化两个字符串：
由于没有提供日志函数，我们假设使用`DEBUG_DHCPS`，并且我们添加一个标准化函数（简单起见，只处理横线分隔，并转为大写）：
```c
static void normalize_mac(char *mac) {
// 将mac字符串中的任何分隔符（比如冒号、点）替换为横线，并转为大写
// 这里我们只处理横线，并转为大写
if (!mac) return;
for (char *p = mac; *p; p++) {
if (*p == ':' || *p == '.') {
*p = '-';
}
*p = toupper((unsigned char)*p);
}
}
```
然后，在比较前：
```c
char normalizedCidStr[64] = {0};
char normalizedPStr[64] = {0};
strncpy(normalizedCidStr, cidStr, sizeof(normalizedCidStr)-1);
strncpy(normalizedPStr, pStr, sizeof(normalizedPStr)-1);
normalize_mac(normalizedCidStr);
normalize_mac(normalizedPStr);
findFlag = STR_EQUAL(normalizedPStr, normalizedCidStr) ? TRUE : FALSE;
```
这样，无论传入的MAC地址是何种分隔符或大小写，都会统一为标准格式（大写横线分隔）进行比较。
注意：这个标准化函数可能不够健壮，但用于MAC地址的简单标准化可能足够。
另外，在`uiDhcpServerGetManualBindWithOptionByCid`中，我们只处理MAC地址的情况（`isMac`为TRUE），如果是客户端ID，则不需要标准化。
所以，修改如下：
```c
if (PFM_ERR_C_OK == tpConfig_IterGetStrPtr(pIter, &pStr, pKey, cidField))
{
DEBUG_DHCPS("get_obj cidStr[%s], input cidStr[%s]\r\n", pStr, cidStr);
if (isMac) {
char normalizedCidStr[64] = {0};
char normalizedPStr[64] = {0};
strncpy(normalizedCidStr, cidStr, sizeof(normalizedCidStr)-1);
strncpy(normalizedPStr, pStr, sizeof(normalizedPStr)-1);
normalize_mac(normalizedCidStr);
normalize_mac(normalizedPStr);
findFlag = STR_EQUAL(normalizedPStr, normalizedCidStr) ? TRUE : FALSE;
} else {
findFlag = STR_EQUAL(pStr, cidStr) ? TRUE : FALSE;
}
break;
}
```
这样修改后，MAC地址格式不一致的问题应该能解决。
2. 如果问题仍然存在，那么就需要检查`uiDhcpServerGetManualBindWithOption`函数了。
由于我们无法看到该函数，所以只能建议检查该函数是否正确地读取了选项字段，并填充到`optionList`数组中。
在`dhcpServerManualBindOutput`函数中，我们也可以添加调试信息，输出`ret`和`optCount`，以及`getoptionList`中每个选项的`code`和`valStr`。
例如，在for循环之后：
```c
for (int i = 0; i < optNum; i++)
{
if (getoptionList[i].code != 0)
{
sprintf(optionLable, "option%d", getoptionList[i].code);
json_object_set_string(pItemObj, optionLable, getoptionList[i].valStr);
DEBUG_DHCPS("Option: code=%d, value=%s", getoptionList[i].code, getoptionList[i].valStr);
optCount++;
}
}
```
这样，我们就能知道是否获取到了选项。
综上所述，首先尝试解决MAC地址格式问题，如果无效，再深入调查`uiDhcpServerGetManualBindWithOption`函数。
由于问题描述中无法看到调试信息，所以以上为基于代码的推测。
因此，我建议先标准化MAC地址的格式，并添加调试日志，以定位问题。
如果问题仍然存在，请提供`uiDhcpServerGetManualBindWithOption`函数的代码，以便进一步分析。
注意：由于是生产代码，修改前请备份，并在测试环境中验证。
由于问题复杂，无法直接给出完整解决方案，但以上步骤应该能帮助定位问题。
最后，由于问题要求“详尽的给出解决方案，尽可能的给出代码”，但问题涉及未提供的函数和具体环境，所以只能给出部分代码和思路。
这里给出修改`uiDhcpServerGetManualBindWithOptionByCid`函数的代码片段（添加MAC地址标准化）：
注意：需要添加`normalize_mac`函数，并在比较前使用。
修改后的`uiDhcpServerGetManualBindWithOptionByCid`函数的部分代码：
```c
// 添加一个辅助函数，用于标准化MAC地址
static void normalize_mac(char *mac) {
if (mac == NULL) {
return;
}
// 先将所有字母转为大写
for (char *p = mac; *p != '\0'; ++p) {
*p = toupper((unsigned char)*p);
}
// 如果存在冒号或点号，替换为横线
// 注意：这里假设字符串中不会同时出现多种分隔符
// 如果已经是横线，则不用替换
for (char *p = mac; *p != '\0'; ++p) {
if (*p == ':' || *p == '.') {
*p = '-';
}
}
}
int uiDhcpServerGetManualBindWithOptionByCid(char *cidStr, BOOL isMac, char *poolName, MANUAL_BINDING *manualBind, OPTION optionList[], int optMaxNum)
{
// ... 前面的代码不变
TPCONFIG_ITER_KEY(pIter)
{
char *pKey = tpConfig_getKeyName(&stGetInfo.iterName);
DEBUG_DHCPS("get_fuzzy key[%s]\r\n", pKey);
char *pStr = NULL;
BOOL findFlag = FALSE;
TPCONFIG_ITER_FV(pIter)
{
if (PFM_ERR_C_OK == tpConfig_IterGetStrPtr(pIter, &pStr, pKey, cidField))
{
DEBUG_DHCPS("get_obj cidStr[%s], input cidStr[%s]\r\n", pStr, cidStr);
if (isMac) {
char normalizedCidStr[64] = {0};
char normalizedPStr[64] = {0};
strncpy(normalizedCidStr, cidStr, sizeof(normalizedCidStr)-1);
strncpy(normalizedPStr, pStr, sizeof(normalizedPStr)-1);
normalize_mac(normalizedCidStr);
normalize_mac(normalizedPStr);
findFlag = STR_EQUAL(normalizedPStr, normalizedCidStr) ? TRUE : FALSE;
} else {
findFlag = STR_EQUAL(pStr, cidStr) ? TRUE : FALSE;
}
DEBUG_DHCPS("After normalize: input[%s], from db[%s], findFlag=%d", normalizedCidStr, normalizedPStr, findFlag);
break;
}
}
// ... 后续代码不变
}
// ...
}
```
这样修改后，MAC地址比较时就会忽略大小写和分隔符的差异。
请测试这个修改是否能解决问题。
如果问题依旧，请检查`uiDhcpServerGetManualBindWithOption`函数的实现。
由于问题中未提供该函数，我们无法进一步分析。
因此，最后的相关问题将围绕这个主题。
</think>根据提供的代码和问题描述，读取不到正确的`dhcp_option_bind`和配置选项值的原因可能涉及以下几个方面。以下是详细分析和解决方案：
### 问题分析
1. **MAC地址格式不一致**：
- Redis中存储的MAC地址为`00-0A-EB-00-13-04`（带横线）
- 传入的`manualBind.macStr`格式可能不同（如冒号分隔或小写）
- 在`uiDhcpServerGetManualBindWithOptionByCid`中直接比较字符串会导致匹配失败
2. **选项解析逻辑缺陷**：
- `uiDhcpServerGetManualBindWithOptionByCid`在找到匹配项后调用`uiDhcpServerGetManualBindWithOption`
- 但`uiDhcpServerGetManualBindWithOption`（未提供实现）可能未正确解析Redis中的选项字段（如`optionType60`, `optionVal60`）
3. **迭代器处理效率问题**：
- 代码注释提到嵌套表和迭代器重置问题（`TODO:优化效率`）
- 当存在大量绑定时，可能提前终止遍历导致匹配失败
### 解决方案
#### 1. 标准化MAC地址比较
修改`uiDhcpServerGetManualBindWithOptionByCid`，添加MAC地址格式化函数：
```c
// 添加在文件顶部
#include <ctype.h>
// MAC地址标准化函数
static void normalize_mac(char *mac) {
if (!mac) return;
char *p = mac;
while (*p) {
if (*p == ':' || *p == '.') *p = '-';
*p = toupper((unsigned char)*p);
p++;
}
}
// 修改匹配逻辑部分
int uiDhcpServerGetManualBindWithOptionByCid(char *cidStr, BOOL isMac, char *poolName, MANUAL_BINDING *manualBind, OPTION optionList[], int optMaxNum) {
// ... [原有代码]
TPCONFIG_ITER_FV(pIter) {
if (PFM_ERR_C_OK == tpConfig_IterGetStrPtr(pIter, &pStr, pKey, cidField)) {
if (isMac) {
char normalizedCid[64] = {0};
char normalizedDB[64] = {0};
strncpy(normalizedCid, cidStr, sizeof(normalizedCid)-1);
strncpy(normalizedDB, pStr, sizeof(normalizedDB)-1);
normalize_mac(normalizedCid);
normalize_mac(normalizedDB);
findFlag = (strcmp(normalizedDB, normalizedCid) == 0);
} else {
findFlag = (strcmp(pStr, cidStr) == 0);
}
break;
}
}
// ... [原有代码]
}
```
#### 2. 添加选项读取调试日志
在`dhcpServerManualBindOutput`中添加日志定位选项读取问题：
```c
static int dhcpServerManualBindOutput(void *data, void *ctx) {
// ... [原有代码]
ret = uiDhcpServerGetManualBindWithOptionByCid(manualBind.macStr, TRUE, manualBind.poolName, &manual_bind, getoptionList, optNum);
// 添加调试日志
DEBUG_DHCPS("uiDhcpServerGetManualBindWithOptionByCid returned: %d", ret);
for (int i = 0; i < optNum; i++) {
if (getoptionList[i].code != 0) {
DEBUG_DHCPS("Got Option: code=%d, value=%s",
getoptionList[i].code,
getoptionList[i].valStr);
}
}
// ... [原有代码]
}
```
#### 3. 修复迭代器遍历逻辑
优化键值遍历逻辑，确保完整遍历所有可能匹配项：
```c
// 修改迭代器逻辑
TPCONFIG_ITER_KEY(pIter) {
char *pKey = tpConfig_getKeyName(&stGetInfo.iterName);
DEBUG_DHCPS("Processing key: %s", pKey); // 添加日志
BOOL findFlag = FALSE;
TPCONFIG_ITER_FV(pIter) {
// ... [标准化MAC比较逻辑]
}
if (findFlag) {
// ... [原有处理逻辑]
break; // 找到匹配后立即跳出，提高效率
}
}
```
### 关键解释
1. **MAC标准化**：
- 将输入MAC和数据库MAC统一转为大写并替换分隔符为横线
- 解决因格式差异导致的匹配失败问题
2. **选项调试**：
- 检查`uiDhcpServerGetManualBindWithOption`实现
- 确保其正确解析Redis中的`optionTypeXX`/`optionValXX`字段
- 验证选项值是否复制到`OPTION.valStr`
3. **性能优化**：
- 找到匹配后立即跳出循环，避免无效遍历
- 处理大量绑定时显著提升效率
### 验证步骤
1. 确认标准化后的MAC一致（如输入`00:0a:eb:00:13:04`会被转为`00-0A-EB-00-13-04`）
2. 检查调试日志是否显示正确选项值
3. 验证返回的JSON是否包含`option60`和`option150`字段
本文深入讲解了DB_DataObject的使用方法，包括配置选项、自动构建和数据库模式创建、工厂方法、查询、插入、更新和删除操作，以及如何进行高级筛选、连接和数据选择。同时还介绍了错误处理、类型转换和调试技巧。
扫一扫
334
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
