我需要运行一个用Tcl编写的Web服务器，默认情况下它依赖于一个硬编码的端口号来监听，但如果该端口已经被使用，我恐怕会导致它失败。它允许您传入一个端口号作为参数，但如果您还没有确定它是一个未使用的端口，那么这可能会导致同样的问题。
我已经设计了以下方法来获得一个看似可以工作的未使用端口（参见最后一行旁边），并且失败的可能性（即端口在中间时间内被使用）似乎更多比仅依靠随机选择的端口号更轻薄。尽管我并不完全满意，但我想知道可能有什么方法来实现这一目标。
/home/ish/Desktop/react-native/restaurant/node_modules/react-native-google-signin/android/src/main/java/co/apptailor/googlesignin/RNGoogleSigninPackage.java:25: error:
method does not override or implement a method from a supertype
@Override
^
1 error
:react-native-google-signin:compileReleaseJavaWithJavac FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':react-native-google-signin:compileReleaseJavaWithJavac'.
> Compilation failed; see the compiler error output for details.
答案 0 :(得分：3)
实际上并没有那么多你可以做的事情理论上，当你没有自己打开套接字时，可以在任何时候打开套接字，但是保持在短暂的端口范围之外（即从32768（0x8000）向上的端口到65535（0xFFFF））将有所帮助，因为您不会遇到TCP连接的客户端自动分配端口的问题。
作为普通用户运行的本地Web服务器的常用端口号是8000和8080（HTTPS的8443），但实际端口号通常并不重要。关键是您通常将这些端口计划为机器整体计划的一部分;你可以有一个很好的主意，因为你可以控制系统，没有任何东西可以干扰。虚拟机使这一切变得更加简单（在完全部署方案中，您使用apache或nginx代理使所有内容都显示在受系统保护的端口80和443之后）。
或者，您使真实系统打开伪端口0（如在脚本中），然后报告实际分配的端口，然后继续为该端口提供真实服务。这是对你现在所做的一个微不足道的扩展...在一个层面，但要求你的整个系统设置为非恒定的端口号。这可能很困难，而且通常只对测试框架很有用（Tcl自己的测试套件使用这个技巧很多）或底层协议的设计是从头开始设计的。