这里的“removed”指的是它们是否在jdk 9中被完全删除，还是被标记为过时了？
有些已经被标记为过时。其他一些则完全被删除了，但通常不是在Java 9中。大多数删除是后来进行的，有些仍将发生。如果您查看现在被注释为@Deprecated的元素，则该注释在某些情况下将正式指示该元素将被删除。
以上说法如果项目使用jdk 8编译，那么在jdk 17上运行是否会出现问题？
不一定。另一件事是逐步关闭对“内部”Java SE API的访问。因此，如果您的应用程序使用这些API，在Java 9中，您会收到警告；在Java 11中，默认情况下会收到错误；而在Java 17中，某些访问已经变得（我认为）不可能。
因此...可能会出现“问题”。
正确的迁移方法是开始执行。并且测试、测试、测试，直到解决了所有问题。
显然，这意味着您需要一个测试服务器，并且您需要使用具有单元测试、功能测试、UI测试等自动化测试框架。但那些只是良好的软件工程实践。您应该已经在遵循它们。
我打算在jdk 8中进行编译，然后在jdk 17上运行，直到整个项目符合jdk 17的标准（我指使用更新的API而不是jdk8中现有的过时API）。这样做是否正确？
不是。正如@Holger所指出的那样，您可能会遇到很多运行时错误...由于Java 17编译器已经确定的问题。
实际上只有一种方法。在Java 17上编译，直到您已经确定了所有的编译时依赖问题；也就是说，使用已删除或关闭的API。然后在Java 17上运行和测试，测试并测试，直到找到所有其他问题为止。
开始之前，建议检查项目的所有依赖项（库等），以查看它们是否受Java 17支持。然后将它们更新到正确的（可能是最新的）版本。
Java 17仅发布了几周，因此您的一些依赖项可能还没有跟上。如果是这种情况，现阶段针对Java 11 LTS可能是更好的选择。
