The short answer is:
Yes. By definition, a router must have more than one interface (with an IP address per interface) to send and receive packets and forward packets from one to the other based on the destination addresses of the packets. Not all routers speak only IP, but “multi-protocol” routers are not really necessary now that everything speaks IP.
The more complex answer is also yes…
The typical implementation of a router has an IP address per “directly attached network” or subnet the router can reach via a local network. (ie if the router has an address 10.10.10.1/23 it can reach any IP address between 10.10.10.1 through 10.10.11.254 from that interface). Hosts on that layer 2 network and in that address space would be configured to use 10.10.10.1 as their “default route” so any traffic not going to 10.10.10.1/23 would be given to the router to send to the final destination. At this point, hopefully the router has one more IP address which it uses to communicate with that router’s default route (or the other directly attached network that has the destination address).
In addition to having more than one IP address, routers may even have more than IP network such that the same IP address exists on several different subnets in the router and the router knows that if traffic from interface A is destined to 10.10.10.10 it goes out interface C, but if it comes in from interface B it must go to interface D. The two most common situations where this can happen are with management networks or with “virtual routers” where a single router is partitioned into different virtual routers for different non-related clients.
It is even possible for a thing that I would call a router to not have an IP address, such as if you have what everyone else calls a “firewall” in bridging mode that enforces policy routes. Such a device would be a nightmare to support and confuse the people who take over for you after you’re fired, but it does route and it doesn’t have a local IP address. (the lunatic who implements such a thing would obviously manage it from a serial port, right?)