Answers:
正如heemayl在评论中指出的，手册页回答了您的问题。通过网络：
想要=
Requires =的较弱版本。如果是配置单元，则将启动此选项中列出的单元。但是，如果列出的单元无法启动或无法添加到事务中，则这对事务整体的有效性没有影响。这是将一个单元的启动与另一单元的启动挂钩的推荐方法。
和Requires =：
配置对其他单元的需求依赖性。如果激活了本机，此处列出的单元也将被激活。如果其他单元之一被停用或激活失败，则该单元将被停用。可以多次指定此选项，也可以在一个选项中指定多个以空格分隔的单位，在这种情况下，将为所有列出的名称创建需求依赖关系。请注意，需求依赖关系不会影响服务启动或停止的顺序。必须使用After =或Before =选项独立配置。如果单元foo.service需要使用Requires =配置的单位bar.service，并且没有通过After =或Before =配置的顺序，则如果激活foo.service，则两个单元将同时启动并且彼此之间没有任何延迟。经常，
请注意，此依赖关系类型并不意味着当该单元运行时，另一个单元始终必须处于活动状态。具体来说：条件检查失败（例如ConditionPathExists =，ConditionPathExists =，…—参见下文）不会导致依赖于Requires =的单元的启动作业失败。此外，某些单元类型可能会自行停用（例如，服务进程可能决定完全退出，或者用户拔出设备的电源），这不会传播到具有Requires =依赖关系的单元。结合使用BindsTo =依赖类型和After =可以确保没有特定的其他单元也处于活动状态时，一个单元永远不会处于活动状态（请参见下文）。
您的服务仅在达到multi-user.target时启动（我不知道如果尝试将其添加到该目标中会发生什么？），而systemd将尝试在服务之前启动display-manager.service。。如果display-manager.service由于任何原因失败，您的服务仍将启动（因此，如果您确实需要display-manager，请使用Requires=该服务）。但是，如果未达到multi-user.target，则不会启动您的服务。
您的服务是什么？它是信息亭系统吗？直觉上我想你想你的服务添加到multi-user.target（所以它在启动时启动），并将它严格地依赖于显示manager.service通过Requires=display-manager.service。但这只是疯狂的猜测。
我们的服务器部署使用包含所有用户ID和自动挂载映射的LDAP。用户主目录是NFS挂载的，用户通常在其主目录中使用可执行代码创建@reboot cronjobs。我们还将sssd用于缓存。不用说，我们高度依赖能够为该配置提供确定的启动顺序。我们开发了一个非常简洁的systemd配置，并发现“ want”和“ requires”部分选项之间的细微差别。
如果您在引导过程中出现服务故障，并且在该服务上存在另一个依赖于该服务的服务，并且该服务具有“ require = always”，则该服务将不会重新启动。但是，如果您有“想要”作为选项，则依赖服务将按预期方式重新启动。
man systemd.unit