why just return NGX_ERROR when the ipv4 addr is failed to parse and the no_resolve is set to 1

The IPv4 address might be wrong, but the URL is not, so it is not an error. The URL may contain a domain name or an upstream name, and both of these cases can be handled later, as many examples of no_resolve in our code show (e.g. ngx_ssl_ocsp_request/ngx_ssl_ocsp_responder). Returning NGX_ERROR in the location you highlighted would not allow to distinguish a wrong URL from a wrong IP address.

And if you have to enforce that the URL is an IP address, you are expected to do something like this:

if (ngx_parse_url(pool, u) != NGX_OK || u->naddrs == 0
    || u->family == AF_UNIX)
{
    /* not an IP address */
    return NGX_ERROR;
}

IPv4 地址可能错误，但 URL 正确，因此这不是错误。URL 可能包含域名或上游名称，这两种情况都可以稍后处理，正如no_resolve我们的代码中的许多示例所示（例如 ngx_ssl_ocsp_request/ ngx_ssl_ocsp_responder）。返回NGX_ERROR您突出显示的位置无法区分错误的 URL 和错误的 IP 地址。

如果您必须强制 URL 是 IP 地址，则需要执行以下操作：

if (ngx_parse_url(pool, u) != NGX_OK || u->naddrs == 0
    || u->family == AF_UNIX)
{
    /* not an IP address */
    return NGX_ERROR;
}

Thank you for your explanation. It means that if I set no_resolve = 1. The url still may not ip addr. I'm quite curious which environment will use no_resolve = 1 and the url is domain name

The main reason to use no_resolve is to avoid calling ngx_inet_resolve_host from the worker process. The function defers the address translation to the routines from libc (getaddrinfo/gethostbyname), which are blocking and have unpredictable execution time, The timeout for these functions is measured in seconds, and it's absolutely not acceptable to stop traffic processing for that long while the hostname is being resolved.
That is why we can only call ngx_parse_url with the no_resolve = 0 while reading the configuration, as it happens in a separate process and does not block the traffic.

In the case when we need to get the address in the worker process, we use a non-blocking asynchronous API from src/core/ngx_resolver.h. SSL OCSP methods I mentioned above are good examples. The implementation of variables in HTTP proxy (proxy_pass http://$arg_upstream_host:80) is another, more complex example, split between ngx_http_proxy_module and ngx_http_upstream_init_request.

I totally understand now. Thank you very much for your explanation. I have no further questions. Have a great day! totally understand！