If you want to customize the http status code, which interval is reasonable and will not conflict with the predefined status code?

because recently RESTful specification is being followed to write api interface, according to the specification, the operation result should be represented by http status code, not in the result set:

{
    code: 200 , 
    msg: "" ,
    ....
}

return. Encounter a scene:

some special errors (such as the need for further action based on the specific status code client) need to return an explicit status code rather than the same as a normal error.

in which interval should a custom http status code be defined properly? And will not conflict with predefined or reserved status codes?

Restful http

Jun.24,2022

refer to RFC https://tools.ietf.org/html/r...

For example, if an unrecognized status code of 471 is received by a
client, the client can assume that there was something wrong with its
request and treat the response as if it had received a 400 (Bad
Request) status code.  The response message will usually contain a
representation that explains the status.

the error code follows the agreement first, which is represented by 1-5. If the last two are not known, the client will assume 100 / 200 / 300 / 400 / 500

The status codes listed below are defined in this specification,
Section 4 of [RFC7232], Section 4 of [RFC7233], and Section 3 of
[RFC7235].  The reason phrases listed here are only recommendations
-- they can be replaced by local equivalents without affecting the
protocol.

some general recommendations do not overwrite, but you can customize the override

Previous: Is there any garbled code on the reporting page title?

Next: How to simulate a browser to access the page to reproduce the problem and debug debug