If the goal is puzzle generation, a backtracking solver is the wrong tool. When it comes to logic puzzles of this sort (Sudoku, Nonograms, etc) people don't like backtracking. There's often even an explicit promise that the puzzles can be solved with "just logic, no guessing needed".
So what you want is a solver that uses only the kinds of (usually local) reasoning that a human would use. I don't have examples handy for Sudoku, but for Nonograms it would be things like this: https://webpbn.com/solving.html
An added benefit is that this allows you to figure out how difficult the puzzle is to solve. What forms of reasoning are needed? How many squares are solvable at any one time? A backtracking solver, especially one that doesn't use any sort of heuristics, can't give that.
For my site I use a backtracker to find a large number of single solution puzzles (rather fast). Those are used as a test base for my "human" solver (pretty slow), which are used for scoring and difficulty levels. I find that it's a nice balance.
Unless the problem space allows you to keep searching after a solution and discard it if a second one is found.
Heuristics are fast and natural, but hard to get right. They're handy to constrain the problem space though, but I would still apply backtracking just in case there's a valid single solution.
Writing a sudoku solver is my go to for learning new programming languages. I just write the most basic algorithm: solve obvious squares with only one answer, then guess and repeat. Backtrack your guess if you end up in an unsolvable case.
It forces you to touch on enough different language features to really get comfortable. Arrays/basic data structures, calling recursive functions, deep copying stuff, fork/join style parallelization (and cancelation if you want).
It's just tricky enough to make you taste some of the code management features like classes and interfaces and the like too.
If you're trying to learn OOP vs. functional programming I think it's a great way to really feel the strength and pain points of both.
My first effort was the same but without backtracking. I would make a random guess at each step and propogate constraints on the board. If it ever got stuck as unsolvable, I would just start it over again. Most solved very quickly, the highest number of tries I had was something like 2100.
That is the complete source code. It says: there are eighty-one numbers, all between one and nine inclusive, and they obey these twenty-seven applications of the Pigeonhole Principle. It will solve, validate, and generate Sudoku puzzles.
So what you want is a solver that uses only the kinds of (usually local) reasoning that a human would use. I don't have examples handy for Sudoku, but for Nonograms it would be things like this: https://webpbn.com/solving.html
An added benefit is that this allows you to figure out how difficult the puzzle is to solve. What forms of reasoning are needed? How many squares are solvable at any one time? A backtracking solver, especially one that doesn't use any sort of heuristics, can't give that.